szotasz/marveen/github-pr-rebase-merge

GitHub PR rebase + merge for conflicting fork PRs

Mikor használd

• 2+ nyitott PR ugyanazon a repo-n, ami átfed fájlokon (pl. src/web.ts)
• A PR-ok EXTERNAL forkból jönnek (head ref: someuser:branch), nem a saját repóból
• User azt kéri, hogy sorban mergeld mindet
• Nem tudsz pusholni a PR branch-ére (nincs write access a forkhoz)

Az alap probléma

Ha két PR (A, B) ugyanazt a fájlt módosítja, az egyik merge után a másik CONFLICTING lesz a GitHub UI-ban, és gh pr merge B elbukik. Külső forkhoz nem tudsz force-pusholni egy rebaselt változatot, szóval két opció marad:

1. A szerző rebaselje manuálisan és pusholja (lassú, emberfüggő)
2. Lokálisan rebaseled, majd squash-mergeled main-be, és a PR-t manuálisan close-olod -- ez a skill

Eljárás

1. Ellenőrzés és tiszta mergek (no conflict)

gh pr view <N> --json mergeable,mergeStateStatus
# MERGEABLE + CLEAN -> gh pr merge N --squash --delete-branch
# UNKNOWN -> várj 5-10 mp-et és újra kérdezd le (GitHub lazy-resolve)
# DIRTY + CONFLICTING -> menj a konfliktus-útra

Mindegyik merge után:

git pull --ff-only origin main
sleep 8  # GitHub időt igényel a mergeable status újraszámolására

2. Konfliktus út (rebase + manual merge)

# 1. Húzd le a PR-t lokális tracking branch-re
gh pr checkout <N>
 
# 2. Rebaseld main-re
git rebase main
# Konfliktus lesz. Rendezd a markereket (<<<<<<< / ======= / >>>>>>>)
# Tipikus eset: két branch új importot adott ugyanahhoz az import blokkhoz -- mindkettőt tartsd meg
# Tipikus eset: komment blokkok -- kombináld őket egy új kommentbe
# Tipikus eset: ugyanazt a függvényt módosítják más célból -- olvasd mindkettőt és integráld
 
git add <rendezett fájlok>
git rebase --continue
 
# 3. Lokálisan teszteld
npm run typecheck
npx vitest run
 
# 4. Próbáld pusholni a PR branch-re
git push --force-with-lease
# Ha "rejected (stale info)" vagy "remote rejected" -> nincs write access, menj a 5. pontra

3. Ha nincs push access (fork scenario)

# Checkoutold main-re, squash-mergeld a rebaselt branchet
git checkout main
git merge --squash <rebaselt-branch-név>
 
# Commitold co-author-ral
git commit -m "$(cat <<'EOF'
<eredeti PR title> (#N)
 
Rebased and merged manually due to conflict with <prior PR or series>.
 
Co-authored-by: <szerző> <szerző-email>
EOF
)"
 
git push origin main
 
# Zárd a PR-t manuálisan
gh pr close N --comment "Merged manually via rebase due to conflict with <prior PR>. See <commit-sha> on main." --delete-branch

Buktatók

• `gh pr merge` nem elég, ha CONFLICTING. Ne próbálkozz vele, mert --merge vagy --rebase flag se oldja meg, ha a patch egyszerűen nem applikál. Menj egyenesen a lokális rebaselésre.
• `gh pr checkout N` után a branch név a PR head ref-je, pl. v3-07-mcp-state-detection. Ne tévesszen meg, hogy lokális branchként jelenik meg. Push-kor az origin a FORK URL-je (<owner>/<repo>.git), nem a saját origin.
• "Skipped deleting the remote branch of a fork" üzenet normális gh pr close --delete-branch-nál. Csak a lokális branchet törli.
• GitHub `mergeStateStatus: UNKNOWN` átmeneti állapot, ~5-15 másodperc alatt konszolidálódik. Ne legyél türelmetlen, várj.
• Ha több sorszám-szám-csúsztatás konfliktus van egy fájlban (pl. 3-4 marker blokk), szemantikusan oldd meg, nem csak mechanikusan. Olvasd fel a környező kódot és gondold át, mit próbál mindkét verzió csinálni.
• A `co-authored-by` fontosság: GitHub így még mindig hozzárendeli a szerzőnek a commitot, és a PR-ra "closed" státuszt rak, nem "merged"-et, de a kód bent van.
• Miután pusholtál main-re, a TÖBBI nyitott PR state UNKNOWN -> CLEAN vagy DIRTY lesz. Mindegyiknél újra kell nézni a státuszt merge előtt, mert lehet hogy a frissen mergelt commit új konfliktust generált.
• `--delete-branch` flag a stacked PR-eket ZÁRJA, NEM CLOSE-olja. Ha a PR base branch-e egy MÁSIK feat-branch (pl. a PR base = feat/slack-channel-request-workflow), és a parent PR-t gh pr merge ... --delete-branch-csel mergeled, a base törlődik és a child PR state=CLOSED lesz automatikusan -- ÉS gh pr reopen "Cannot open the pull request" hibát ad ÉS gh pr edit --base main "Cannot change the base branch of a closed pull request"-ot. Megoldás: új PR-t nyitni ugyanabból a head branchből (gh pr create --base main --head <branch>). A korábbi review-history a régi PR-on marad — link-eld be hivatkozással ("Re-opened after the prior PR closed when its base branch was deleted").
• Az orchestrator-install branch-stuck: az orchestrator agent lokál git checkout-ja a rebase-conflict resolution közben véletlenül a feat-branchen ragad (pl. tmp-pr-rebase-ből git push origin tmp:feat/X --force után a checkout helyben marad). Az update.sh Guard 1: refuse non-main branch ezt megfogja, és az update.sh exit-el — de a dashboard UI pending commits-ot listáz, és a "Frissítés most" gomb úgy tűnik mintha "legfrissebb verzión" lennél. Diagnózis: git -C <project-root> branch --show-current. Megoldás: git stash push -u, git checkout main, git pull --ff-only, git stash pop. Build+restart aztán.

• A `npm run build && stop && start && stash pop` chain SIGKILL/exit-137 OOM. A merge utáni manuális update-flow-t NE chain-eld egy shell-hívásba (a tsc build memóriafogyasztó, és a chain alatt a memória gyűlik → exit 137, build befejezetlen, services down). Helyes: minden lépés KÜLÖN hívásban (1: build, 2: stop, 3: start, 4: stash pop). A canonical út amúgy az update.sh, ami helyesen sorban csinálja.

• A `stop.sh` UNLOAD-olja a launchd jobot → a KeepAlive NEM hozza vissza automatikusan. A com.<slug>.dashboard.plist-ben KeepAlive=true, DE a stop.sh launchctl unload-dal áll le. Az unload SZÁNDÉKOS leállítás, a KeepAlive csak CRASH-re indít újra, unload-ra NEM. Ezért stop.sh után a fő-agent lent marad, amíg launchctl load (start.sh) vissza nem tölti. TANULSÁG: ha manuálisan stop.sh-zol update közben, MINDIG futtass utána start.sh-t magadtól, ne várj az operátorra. FONTOS: a stop.sh SZÁNDÉKOSAN NEM állítja le a sub-agenteket (csak a ${SLUG}-channels fő-session-t — explicit komment a scriptben). Ha update után a sub-agentek mégis lent vannak, az NEM a stop.sh miatt van, vizsgáld külön; helyreállítás egyenként: POST /api/agents/<name>/start (Bearer token) + tmux has-session -t agent-<name> ellenőrzés.

Ellenőrzés

• Minden PR után: gh pr view <N> --json state,mergedAt -> MERGED vagy CLOSED
• Végén: gh pr list --limit 10 -> a listán ne legyen a mergelendő PR-ok egyike
• Végén: npm run typecheck && npx vitest run a friss main-en -> minden zöld
• Végén: git log --oneline -10 -> minden PR commitja ott van a main-en

Példa

Ha a user azt írja: "8 PR van, menj sorban, review és merge", és 3 egymás után konfliktál (mert mindegyik src/web.ts-t szerkeszti), az idő-becslés ~3-5 perc PR-onként konfliktussal, ~30 mp PR-onként clean merge-nél. Küldj progress update-et 50%-nál, hogy a user tudja haladsz.