GitHub Stacked PRs: Så funkar kedjade pull requests och varför ditt team borde bry sig

En Reddit-tråd med 456 poäng på r/programming öppnade en debatt som de flesta utvecklarteam känner igen: stora pull requests tar evigheter att granska, reviewer scrollar förbi 80% av koden, och hela teamet blockeras medan någon väntar på en godkännandestämpel. GitHub svarar nu med stacked PRs — och communityn är delad.

Microsofts forskning på över 700 000 kodgranskningar visar att reviewers kommenterar på 7% av metoderna i små changesets, men bara 2-3% i stora. Ju större PR, desto sämre granskning. Stacked PRs är ett försök att lösa det problemet.

Vad är stacked PRs?

I stället för att skicka in en PR med 2 000 rader delar du upp arbetet i en kedja av mindre PRs som beror på varandra. Varje PR i stacken riktar sig mot branchen under den, och den nedersta riktar sig mot main.

# Traditionellt: en stor PR
main ← feature/user-profiles (47 filer, 2 100 rader)

# Stacked PRs: en kedja av små PRs
main ← stack/user-model (3 filer, 120 rader)
     ← stack/user-api (5 filer, 180 rader)
     ← stack/user-ui (8 filer, 250 rader)
     ← stack/user-tests (4 filer, 200 rader)

# Varje PR kan granskas separat
# Reviewern ser 120-250 rader, inte 2 100

Idén är inte ny. Meta har använt det internt i åratal via Phabricator. Google kör commit-baserad granskning i Critique. Men för GitHub-användare har det saknats native stöd — tills nu.

GitHubs preview: Så fungerar det

GitHub lanserade stacked PRs som preview-funktion under 2025. Varje PR i en stack visar en karta över hela kedjan, och du kan navigera mellan delarna direkt i gränssnittet. När en PR längre ner mergeas rebasar GitHub automatiskt resten av stacken.

# Skapa en stack med GitHub CLI
# 1. Första lagret
git checkout -b stack/data-model main
# ... gör ändringar ...
git push -u origin stack/data-model
gh pr create --base main --title "Stack 1/3: Data model"

# 2. Andra lagret bygger på det första
git checkout -b stack/api stack/data-model
# ... gör ändringar ...
git push -u origin stack/api
gh pr create --base stack/data-model --title "Stack 2/3: API endpoints"

# 3. Tredje lagret bygger på det andra
git checkout -b stack/frontend stack/api
# ... gör ändringar ...
git push -u origin stack/frontend
gh pr create --base stack/api --title "Stack 3/3: Frontend"

# GitHub visar nu hela stacken i varje PR

Det är den manuella varianten. I praktiken vill du ha ett verktyg som hanterar rebasing och synkronisering åt dig.

Verktygen: Från Meta till Graphite

Ekosystemet har vuxit snabbt de senaste åren. Här är de relevanta alternativen:

Graphite (kommersiellt)

Det mest polerade alternativet. CLI + webbgränssnitt + VS Code-tillägg. Graphite hanterar hela stacken: skapar PRs, rebasar automatiskt, och har en merge queue som ser till att allt landar i rätt ordning.

# Graphite workflow
gt create -m "Add user data model"
# ... jobba vidare i samma branch ...
gt create -m "Add API endpoints"
# ... fortsätt ...
gt create -m "Add frontend components"

# Pusha hela stacken
gt submit

# Graphite skapar 3 PRs med rätt beroenden
# och rebasar automatiskt vid ändringar

ghstack (Meta, open source)

Metas interna verktyg, nu open source. Commit-orienterat: varje commit blir en egen PR. Kraftfullt men kräver att du tänker i commits, inte branches.

spr (Stack Pull Requests)

Lättviktigt open source-verktyg. Varje commit i din branch blir en separat PR med commit-meddelandet som titel. Minimal overhead.

git-branchless

En helt annan approach: behandlar commits (inte branches) som den primära enheten. Inkluderar smartlog för visualisering, automatisk rebasing, och undo-stöd. Designat för monorepos och hög hastighet.

Fördelarna: Varför 44% av teamen borde bry sig

Microsofts studie visar att 44% av alla utvecklarteam pekar ut långsamma code reviews som sin största leveransflaskhals. Stacked PRs attackerar det problemet från två håll.

Bättre granskningskvalitet. En reviewer som ser 150 rader förstår kontexten. En reviewer som ser 2 000 rader scrollar till botten och skriver "LGTM". Tre oberoende megastudier (Google, Microsoft, Meta) konvergerar på samma slutsats: elitteam håller PRs under 400 rader och cykeltiden under sex timmar.

Ingen blockering. Du behöver inte vänta på att PR #1 mergeas innan du börjar jobba på PR #2. Du bygger vidare direkt och skickar in hela stacken för granskning. Reviewers kan godkänna delarna parallellt.

Enklare rollbacks. Om en bugg dyker upp i produktionen och du vet att den kom in via en stack på 4 PRs, är problemet nästan säkert i den senaste — den med under 200 rader, inte den med 2 000.

Problemen: Det Reddit-tråden inte nämner direkt

Communityn är inte enig. Och problemen är inte triviala.

Rebase-kaskader. Om den nedersta PRen i en stack får merge-konflikter måste varje PR ovanför lösas manuellt, en i taget. Med en stack på 8 PRs kan det bli en eftermiddag av konfliktlösning. Verktygen hjälper, men kan inte eliminera problemet helt.

# Rebase-kaskad: det värsta scenariot
main ← stack/1 (KONFLIKT med main)
     ← stack/2 (måste rebasas efter stack/1)
     ← stack/3 (måste rebasas efter stack/2)
     ← stack/4 (måste rebasas efter stack/3)

# Varje nivå kan introducera nya konflikter
# Med 8 PRs kan det ta timmar att lösa

# Graphite/ghstack hanterar det automatiskt
# MEN bara om konflikterna är triviala
# Manuell lösning behövs fortfarande vid riktiga konflikter

Notifikationsöversvämning. En stack på 12 PRs genererar 12 notifikationer vid varje uppdatering. Reviewers drunknar. CI kör 12 gånger. Det är ett reellt problem i stora team.

Inlärningskurvan. Stacking kräver att hela teamet förstår Git rebasing på djupet. Det är inte en trivial tröskel. En utvecklare som aldrig rebasat manuellt kommer att kämpa med stacked PRs oavsett vilket verktyg som används.

Trunk-based-purister har en poäng. Flera röster i Reddit-tråden argumenterar att behovet av en stack ofta är ett symptom på bristande modularitet. Om du behöver 8 PRs i kedja kanske funktionen borde brytas ner i oberoende delar som kan mergeas separat.

Nordisk kontext: Fungerar det i ditt team?

Spotify och Klarna kör sofistikerade CI/CD-pipelines med kontinuerlig integration som central princip. Det är exakt den typen av miljö där stacked PRs ger mest värde. Men de flesta nordiska team är inte Spotify.

Här är en ärlig bedömning baserat på teamstorlek:

2-5 utvecklare: Du behöver förmodligen inte stacked PRs. GitHub Flow med kortlivade branches fungerar. Problemet med stora PRs löses enklare genom att committa oftare och hålla scope litet.

5-15 utvecklare: Stacked PRs börjar ge verkligt värde. Code review-kön är troligen redan en flaskhals. Prova Graphite eller GitHubs native stöd på en feature och utvärdera.

15+ utvecklare: Du borde redan experimentera med detta. Varje dag som en PR ligger och väntar kostar pengar i context-switching och blockerad utveckling.

Så kommer du igång

Om du vill testa stacked PRs utan att investera i ett nytt verktyg kan du börja med manuella stacks i GitHub:

# Steg 1: Identifiera en kommande feature
# som du kan dela upp i 2-4 logiska delar

# Steg 2: Skapa första branchen från main
git checkout -b stack/1-data-layer main
# Gör dina ändringar, pusha, skapa PR mot main

# Steg 3: Bygg vidare
git checkout -b stack/2-business-logic stack/1-data-layer
# Gör ändringar, pusha, skapa PR mot stack/1-data-layer

# Steg 4: När stack/1 mergeas till main
# Uppdatera base branch för stack/2 till main
# (GitHub gör detta automatiskt med stacked PRs preview)

# Tips: Börja med 2-3 PRs per stack
# Öka INTE till 8+ innan teamet är bekvämt med flödet

Vill du ha automatisering direkt, installera Graphite CLI:

# Installera Graphite
npm install -g @withgraphite/graphite-cli

# Initiera i ditt repo
gt init

# Skapa din första stack
gt create -m "First layer: data model"
# ... jobba ...
gt create -m "Second layer: API"

# Synka och pusha allt
gt submit

Framtiden: GitHub satsar, communityn anpassar sig

GitHubs native stöd förändrar kalkylen. Tidigare krävdes externa verktyg och ett dedikerat team som ville investera i nytt arbetsflöde. Nu räcker det att skapa PRs med rätt base branch, och GitHub visar stacken automatiskt.

Det betyder inte att alla borde börja stacka. Men det betyder att barriären är lägre än någonsin. Om ditt team redan kämpar med stora PRs och långsamma reviews är det värt att testa.

En sak är alla överens om: PRs på 2 000 rader fungerar inte. Frågan är bara om stacked PRs är svaret, eller om disciplin och mindre scope räcker.

Fördjupa dig i branching-strategier med vår guide till Git workflow och branching, eller läs om hur du sätter upp en komplett CI/CD-pipeline med GitHub Actions.