GitHub Stacked PRs: Ein neuer Workflow für große Changes

47 geänderte Dateien. Über tausend Zeilen. Und oben drüber steht: “Sorry, ist ein bisschen groß geworden.” Genau so ein Pull Request liegt gerade wieder in deiner Review-Queue, und schon beim Scrollen durch den Diff merkst du, wie die Motivation kippt.

Du weißt, was jetzt passiert. Du reviewst es nicht wirklich. Du überfliegst es. Du drückst “Approve” mit einem mulmigen Gefühl im Bauch, weil, ehrlich gesagt, wer soll das in dieser Größe noch ernsthaft durchdenken? Und drei Wochen später taucht genau in diesem PR ein Bug auf, den eigentlich jeder hätte sehen können. Nur eben nicht in dieser Masse.

Das ist kein Einzelfall. Das ist im Grunde der Normalzustand in vielen Teams. Und GitHub hat sich das offenbar auch gedacht, denn seit dem 30. Juli 2026 gibt es eine native Antwort darauf: Stacked Pull Requests, seitdem in der Public Preview für alle Repositories verfügbar.

Was sind GitHub Stacked PRs?

Eine Stacked Pull Request ist im Kern eine geordnete Reihe von PRs, bei der jede auf der davor aufbaut. Der unterste PR im Stack zielt auf deinen Trunk, also meistens main. Jeder weitere PR darüber zielt nicht mehr auf main, sondern auf den Branch des PRs direkt darunter. Das Ergebnis: Statt eines 1000-Zeilen-Monsters bekommst du vier PRs mit je 150 bis 300 Zeilen, die inhaltlich trotzdem zusammengehören.

Schematisch sieht so ein Stack aus drei Layern so aus:

main
 └─ PR #1 (Datenstruktur ändern)
     └─ PR #2 (Funktion anpassen)
         └─ PR #3 (Aufrufer updaten)

PR #1 zielt auf main, PR #2 zielt auf den Branch von PR #1, PR #3 zielt auf den Branch von PR #2. Wird PR #1 gemerged, rückt PR #2 automatisch als neuer unterster Layer auf main nach.

Der Clou ist, dass das nicht bloß eine visuelle Spielerei ist. Jeder PR im Stack lässt sich unabhängig reviewen und einzeln absegnen - aber gemerged wird am Ende in einer einzigen Operation. Wenn der oberste, fertig reviewte PR gemerged wird, zieht GitHub automatisch alle noch offenen Layer darunter mit. Reviewer sehen dabei wirklich nur den Diff der jeweiligen Ebene, nicht den kumulierten Wahnsinn des gesamten Changes. Und weil das Feature nativ in GitHub steckt, funktionieren bestehende Reviews, Checks und Merge-Regeln einfach weiter, ohne dass du irgendwas umbauen musst.

Wichtig zur Einordnung, weil die Begriffe gerne durcheinandergehen: Das Konzept selbst heißt in der Community meist “Stacked Diffs” oder “Stacked Branches” und ist nicht neu. Tools wie Graphite oder git-branchless bauen seit Jahren genau darauf auf. Neu ist, dass GitHub es jetzt als natives Feature direkt in die Plattform einbaut, ohne separates Tool, ohne separaten Account für Reviewer.

Das Problem, das Stacked PRs eigentlich lösen

Bevor wir tiefer ins Technische gehen, lohnt sich der Blick auf das, was da eigentlich kaputt ist. Große Pull Requests sind aus gutem Grund unpopulär. Sie sind schwer zu reviewen, weil dein Gehirn nach der dreißigsten geänderten Datei einfach nicht mehr die gleiche Aufmerksamkeit aufbringt wie bei der ersten. Sie blockieren sich selbst, weil schon ein einzelner strittiger Punkt (eine Variable, eine Architekturentscheidung) den kompletten Merge aufhält, auch wenn neunzig Prozent der Änderung unstrittig sind. Und sie verzögern Feedback, weil so ein Monster-PR oft tagelang offen bleibt, bevor sich jemand die Zeit nimmt, ihn wirklich anzuschauen.

Die naheliegende Lösung: kleiner committen, kleiner PRen. Nur ist das in der Praxis schwer umzusetzen, wenn eine Änderung tatsächlich mehrere aufeinander aufbauende Schritte braucht. Du willst zuerst die Datenstruktur ändern, dann die Funktion, die sie nutzt, dann den Aufrufer. Jeder Schritt für sich ist überschaubar. Nur ergibt Schritt zwei ohne Schritt eins keinen Sinn. Und wenn du auf den Merge von Schritt eins wartest, bevor du Schritt zwei überhaupt anfängst, steht deine Arbeit tagelang still. Stacked PRs lösen genau dieses Dilemma: Du arbeitest weiter, während unten im Stack noch reviewt wird.

Wie du einen Stack in der Praxis aufbaust

Los geht’s über die GitHub CLI. Voraussetzung ist gh in einer aktuellen Version sowie die gh-stack-Extension bzw. das integrierte Stack-Kommando, je nachdem, wie weit die Public Preview in deinem Account schon ausgerollt ist. Der Ablauf sieht so aus:

# Stack initialisieren - einmal pro Repository/Feature
gh stack init

# Ersten Branch im Stack anlegen und benennen
gh stack add datenstruktur-aendern

# Code schreiben, dann committen
git add .
git commit -m "Neue Datenstruktur für Order einführen"

# Nächsten Layer oben auf den Stack setzen
gh stack add funktion-anpassen

Praktisch ist auch die Kurzform gh stack add -Am "Nachricht", die in einem Schritt alle Änderungen staged, committet und direkt den nächsten Branch im Stack erzeugt - du sparst dir also das übliche Hin und Her zwischen git add, git commit und Branch-Wechsel. Jeder Branch wird automatisch mit dem korrekten Base-Branch verknüpft, sprich mit dem Branch direkt darunter im Stack.

Sobald du bereit bist, PRs zu öffnen, übernimmt gh stack sync die eigentliche Fleißarbeit: Es holt den aktuellen Stand von origin, rebased deine Branches, pusht sie, verlinkt die offenen PRs zu einem sichtbaren Stack auf GitHub und räumt lokal Branches auf, deren PRs bereits gemerged wurden. Das ist der Befehl, den du eigentlich jedes Mal ausführst, wenn sich unten im Stack etwas verändert hat, zum Beispiel weil der erste PR gerade gemerged wurde und alle Branches darüber jetzt neu aufgesetzt werden müssen.

Ein Überblick über die wichtigsten Befehle, damit du sie nicht ständig nachschlagen musst:

Auf github.com bekommst du für jeden PR im Stack eine Stack-Map direkt in der Oberfläche. Du siehst auf einen Blick, wo dein PR im Gesamtbild steht, was darunter noch offen ist und was schon gemerged wurde. Das funktioniert übrigens nicht nur über die CLI: Du kannst genauso über die Web-Oberfläche oder die GitHub Mobile App arbeiten. Und, was ich wirklich bemerkenswert finde: Auch Coding-Agents wie Claude Code können über einen eigenen gh-stack-Skill selbstständig Layer für Layer anlegen. Merge-Queue-Unterstützung für Stacks rollt GitHub aktuell noch schrittweise aus, ist also noch nicht überall verfügbar.

Was passiert, wenn unten im Stack etwas gemerged wird

Das ist der Teil, der bei Stacked PRs am meisten Respekt einflößt, wenn man es noch nicht gemacht hat. Angenommen, du hast drei PRs im Stack: A (unten), B (Mitte), C (oben). A wird gemerged. Was jetzt?

Ohne Tooling müsstest du B und C händisch umbasen, damit sie wieder auf dem aktuellen main aufsetzen statt auf dem inzwischen gelöschten Branch von A. Genau das übernimmt gh stack sync für dich: Es erkennt, dass A gemerged wurde, hängt B automatisch an main, rebased C entsprechend auf den neuen B, und pusht alles neu. Kommt es dabei zu echten Konflikten, weil sich der Code in A und B überschneidet, hältst du an, löst den Konflikt manuell auf und rufst gh stack continue auf, um weiterzumachen.

Wenn du am obersten PR im Stack “Merge” klickst und alle Layer darunter bereits reviewt und grün sind, merged GitHub sie in einer einzigen Operation von unten nach oben durch. Du musst also nicht vier Mal einzeln auf “Merge” klicken und hoffen, dass zwischendurch niemand einen Konflikt reinbringt.

Best Practices für Stacked PRs

Ein paar Regeln, die sich in der Praxis herausgebildet haben, bei GitHub selbst genauso wie bei Teams, die vorher schon mit Graphite gearbeitet haben:

Ein Layer, eine Idee. Jeder PR im Stack sollte für sich eine sinnvolle, in sich geschlossene Änderung sein, nicht nur ein willkürlich abgeschnittenes Stück eines größeren Diffs. Wenn du einen Layer beschreiben musst mit “das ergibt nur zusammen mit dem nächsten PR Sinn”, ist er wahrscheinlich falsch geschnitten.

Bleib unter 200 bis 300 Zeilen pro Layer. Das ist keine willkürliche Zahl. Eine Auswertung von über 1,5 Millionen Pull Requests durch cubic zeigt: Unter 200 Zeilen werden PRs rund dreimal schneller reviewt, und rund 40 Prozent weniger Bugs schaffen es bis in Produktion. Genau das ist der Punkt von Stacked PRs: Du bekommst die Vorteile kleiner PRs, ohne die große Änderung künstlich zerstückeln zu müssen.

Synchronisiere häufig, nicht erst am Ende. Je länger ein Stack offen bleibt, ohne dass du gh stack sync laufen lässt, desto größer das Risiko divergierender Branches und hässlicher Rebase-Konflikte. Ein Stack, der über Wochen unsynchronisiert bleibt, verliert genau den Vorteil, den er eigentlich bringen sollte.

Kommuniziere die Reihenfolge im Review. Bitte Reviewer, tatsächlich von unten nach oben zu reviewen. Das klingt banal, aber wenn jemand zuerst den obersten PR öffnet, fehlt ihm der Kontext aus den Layern darunter - und das führt zu genau der Verwirrung, die der Stack eigentlich vermeiden sollte.

Nicht jeden Change stacken. Wenn eine Änderung wirklich unabhängig ist, mach einen normalen PR. Stacks lohnen sich, wenn eine Abhängigkeit zwischen den Teilen tatsächlich existiert - nicht als Standard-Workflow für alles.

Für welche Anwendungsfälle sich Stacked PRs wirklich lohnen

Nicht jedes Team braucht das sofort. Der Wert entsteht genau dann, wenn eine Änderung natürlicherweise in Schichten zerfällt. Das klassische Beispiel ist ein größeres Refactoring, das eine spätere API-Änderung vorbereitet: erst die Struktur anpassen, dann die Migration, dann das Aufräumen des alten Codes. Genauso bei Feature-Entwicklung mit Feature Flags, wo du zuerst das Flag und das Grundgerüst baust, danach die eigentliche Logik und zuletzt den Rollout-Code. Oder bei Migrationen von Bibliotheken und Frameworks, die sich über mehrere Module ziehen und sich eigentlich nur Modul für Modul sauber reviewen lassen.

Auch Teams mit hoher Ship-Frequenz profitieren spürbar davon, etwa wenn zehn oder mehr PRs am Tag gemergt werden und niemand darauf warten soll, bis eine lange Review-Kette durch ist.

Wenn du dagegen überwiegend an kleinen, in sich abgeschlossenen Features arbeitest, ändert sich für dich erstmal wenig. Da reicht der normale Ein-PR-Workflow weiterhin völlig aus, und ich würde davon abraten, Stacks künstlich einzuführen, nur weil sie gerade neu sind.

Stacked PRs vs. Graphite und andere Tools

Wer sich mit dem Thema schon beschäftigt hat, kennt wahrscheinlich Graphite, das dieses Muster seit Jahren als eigenständiges Produkt anbietet, oder auch git-branchless und git-town, die ähnliche Workflows über die Kommandozeile ermöglichen. Der entscheidende Unterschied zu GitHubs eigener Lösung: Bei den bisherigen Tools brauchte jeder Reviewer einen eigenen Account oder eine Extension, um den Stack-Kontext überhaupt zu sehen. Stack-Map und Merge-Logik liefen außerhalb von GitHub und mussten erst wieder mit dem eigentlichen Repository synchronisiert werden.

Bei GitHubs nativer Umsetzung lebt der gesamte Stack dagegen innerhalb der Plattform, die dein Team ohnehin täglich benutzt. Du brauchst keinen zusätzlichen Login, keine Extension, kein zweites System, das ständig synchron gehalten werden muss. Das ist der Punkt, an dem die Konkurrenz sich jetzt wirklich warm anziehen muss.

Grenzen und offene Baustellen

Es ist Public Preview, kein fertiges, ausgereiftes Produkt. Beim Rebasing innerhalb eines Stacks, bei Konflikten zwischen Layern und beim Zusammenspiel mit Merge Queues wird sich in den nächsten Monaten noch einiges bewegen. Die Merge-Queue-Unterstützung selbst rollt GitHub aktuell erst schrittweise aus. Wer jetzt einsteigt, testet mit, im positiven wie im nervigen Sinne. Ich würde momentan noch keinen kritischen Release-Branch komplett darauf aufbauen, aber zum Ausprobieren an einem echten, mehrteiligen Change ist es allemal gut genug. Auch organisatorisch brauchst du eine gewisse Disziplin im Team, sonst verkommt der Stack schnell zu einem unübersichtlichen Geflecht aus halb synchronisierten Branches, also genau zum Gegenteil von dem, was er eigentlich bringen soll.

Fazit

Große PRs sind kein Stilproblem, sie sind ein strukturelles. Stacked PRs setzen genau da an: Sie ermahnen dich nicht zu mehr Disziplin, sie unterstützen einfach den Workflow, den viele ohnehin schon im Kopf haben. Schritt für Schritt bauen, Schritt für Schritt reviewen lassen, ohne dass die Arbeit dazwischen stillsteht. Ob sich das für dein Team lohnt, hängt davon ab, wie oft deine Changes tatsächlich in solchen Schichten anfallen. Wenn die Antwort “ständig” lautet, ist jetzt ein guter Zeitpunkt, einen Blick drauf zu werfen.

Vorschaubild: Gabrielle Henderson