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:
- A szerző rebaselje manuálisan és pusholja (lassú, emberfüggő)
- 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.
1---2name: github-pr-rebase-merge3description: Merge a stack of GitHub PRs sequentially when they share files and will cause cascading conflicts. Triggers when user says "merge the PRs sorban" or similar, and the PRs come from external forks (cannot push back to PR branch).4---56# GitHub PR rebase + merge for conflicting fork PRs78## Mikor használd910- 2+ nyitott PR ugyanazon a repo-n, ami átfed fájlokon (pl. `src/web.ts`)11- A PR-ok EXTERNAL forkból jönnek (head ref: `someuser:branch`), nem a saját repóból12- User azt kéri, hogy sorban mergeld mindet13- Nem tudsz pusholni a PR branch-ére (nincs write access a forkhoz)1415## Az alap probléma1617Ha 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:18191. A szerző rebaselje manuálisan és pusholja (lassú, emberfüggő)202. **Lokálisan rebaseled, majd squash-mergeled main-be, és a PR-t manuálisan close-olod** -- ez a skill2122## Eljárás2324### 1. Ellenőrzés és tiszta mergek (no conflict)2526```bash27gh pr view <N> --json mergeable,mergeStateStatus28# MERGEABLE + CLEAN -> gh pr merge N --squash --delete-branch29# UNKNOWN -> várj 5-10 mp-et és újra kérdezd le (GitHub lazy-resolve)30# DIRTY + CONFLICTING -> menj a konfliktus-útra31```3233Mindegyik merge után:34```bash35git pull --ff-only origin main36sleep 8 # GitHub időt igényel a mergeable status újraszámolására37```3839### 2. Konfliktus út (rebase + manual merge)4041```bash42# 1. Húzd le a PR-t lokális tracking branch-re43gh pr checkout <N>4445# 2. Rebaseld main-re46git rebase main47# Konfliktus lesz. Rendezd a markereket (<<<<<<< / ======= / >>>>>>>)48# Tipikus eset: két branch új importot adott ugyanahhoz az import blokkhoz -- mindkettőt tartsd meg49# Tipikus eset: komment blokkok -- kombináld őket egy új kommentbe50# Tipikus eset: ugyanazt a függvényt módosítják más célból -- olvasd mindkettőt és integráld5152git add <rendezett fájlok>53git rebase --continue5455# 3. Lokálisan teszteld56npm run typecheck57npx vitest run5859# 4. Próbáld pusholni a PR branch-re60git push --force-with-lease61# Ha "rejected (stale info)" vagy "remote rejected" -> nincs write access, menj a 5. pontra62```6364### 3. Ha nincs push access (fork scenario)6566```bash67# Checkoutold main-re, squash-mergeld a rebaselt branchet68git checkout main69git merge --squash <rebaselt-branch-név>7071# Commitold co-author-ral72git commit -m "$(cat <<'EOF'73<eredeti PR title> (#N)7475Rebased and merged manually due to conflict with <prior PR or series>.7677Co-authored-by: <szerző> <szerző-email>78EOF79)"8081git push origin main8283# Zárd a PR-t manuálisan84gh pr close N --comment "Merged manually via rebase due to conflict with <prior PR>. See <commit-sha> on main." --delete-branch85```8687## Buktatók8889- **`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.90- **`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.91- **"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.92- **GitHub `mergeStateStatus: UNKNOWN`** átmeneti állapot, ~5-15 másodperc alatt konszolidálódik. Ne legyél türelmetlen, várj.93- **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.94- **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.95- **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.96- **`--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").97- **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.9899- **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.100101- **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.102103## Ellenőrzés104105- Minden PR után: `gh pr view <N> --json state,mergedAt` -> MERGED vagy CLOSED106- Végén: `gh pr list --limit 10` -> a listán ne legyen a mergelendő PR-ok egyike107- Végén: `npm run typecheck && npx vitest run` a friss main-en -> minden zöld108- Végén: `git log --oneline -10` -> minden PR commitja ott van a main-en109110## Példa111112Ha 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.
szotasz