Stacked Pull Requests: Reviews wieder machbar

Der Code ist fertig, bevor der Kaffee kalt ist. Dann liegt der Pull Request einen Tag lang herum, weil niemand Lust hat, 900 geänderte Zeilen in einem Rutsch zu lesen. Wer mit Coding-Agenten arbeitet, kennt das: Geschrieben wird schnell, gelesen wird langsam.

GitHub hat dafür am 06.10.2026 ein Werkzeug allgemein freigegeben, das es bei Meta und Google seit vielen Jahren gibt: Stacked Pull Requests. Eine große Änderung wird in mehrere kleine PRs zerlegt, die aufeinander aufbauen und einzeln geprüft werden. Neu ist die Idee also nicht, und GitHub ist auch nicht der einzige Server, der sie beherrscht. Für GitLab, Gitea und Forgejo gibt es brauchbare Wege.

Das Problem ist der Stau, nicht die Zeilenzahl

Die naheliegende Erklärung lautet: Agenten produzieren riesige PRs. Die Daten geben das nur zum Teil her.

LinearB hat für seine Benchmarks 2026 mehr als 8,1 Millionen Pull Requests ausgewertet. Der Median liegt bei Agenten-PRs bei 89 geänderten Zeilen, ohne KI bei 26. Das ist größer, aber weit weg von 900 Zeilen. Am größten fallen die PRs in der Mischform aus, in der Menschen mit KI-Unterstützung schreiben: Median 96 Zeilen, ein Viertel hat mehr als 408.

Auffälliger ist die Wartezeit bis zum ersten Review, bei LinearB heißt sie Pickup Time. Im 75. Perzentil warten Agenten-PRs 17,6 Stunden, ohne KI sind es 3,4.

Faros AI kam 2025 mit Telemetrie von über 10.000 Entwicklern zu einem ähnlichen Bild: Entwickler in Teams mit hoher KI-Nutzung mergen 98 Prozent mehr Pull Requests, die Review-Zeit steigt um 91 Prozent. Mit der KI-Nutzung wächst dort auch die durchschnittliche PR-Größe, um 154 Prozent. Was die Studie sonst hergibt, steht in KI-Produktivität messen. Beide Auswertungen stammen von Herstellern, die Messwerkzeuge verkaufen, und zeigen Zusammenhänge, keine Ursachen. Sie weisen aber in dieselbe Richtung: Es wird mehr eingereicht, und das Review kommt nicht hinterher.

Dass große Reviews schlechter werden, ist älteres Wissen. Die viel zitierte Untersuchung von SmartBear bei Cisco empfiehlt, nicht mehr als 200 bis 400 Zeilen auf einmal zu prüfen und nicht länger als 60 Minuten am Stück. Die Zahl stammt aus den Daten eines einzigen Unternehmens und taugt nur als Faustregel. Wer schon einmal bei Datei 14 von 31 nur noch durchgescrollt hat, wird ihr trotzdem kaum widersprechen.

Stacks setzen deshalb am oberen Ende der Verteilung an: bei den Änderungen mit mehreren hundert Zeilen, die niemand anfassen will und die genau deshalb am längsten liegen. Dem typischen 89-Zeilen-PR helfen sie nicht.

Was ein Stack ist

Ein Stack ist eine Kette von Branches. Der erste zweigt vom Hauptzweig ab, der zweite vom ersten, der dritte vom zweiten. Zu jedem Branch gehört ein eigener Pull Request, der nur den Unterschied zur Schicht davor zeigt.

flowchart TB
  M["main"] --> A["PR 1: Datenmodell"]
  A --> B["PR 2: API-Endpunkte"]
  B --> C["PR 3: Oberfläche"]

Der Gewinn liegt an zwei Stellen. Reviewer bekommen drei überschaubare Einheiten mit je einem Thema. Und wer schreibt, arbeitet auf der nächsten Schicht weiter, während PR 1 im Review liegt.

Die Idee stammt aus der Welt von Phabricator bei Facebook und aus Gerrit, das von Google kommt. Dort heißt sie Stacked Diffs oder Change-Ketten und ist der Normalfall. Auf GitHub ging das lange nur mit Handarbeit oder Zusatzwerkzeugen, weil jede Änderung an einer früheren Schicht bedeutet, alle folgenden neu aufzusetzen.

GitHub: was jetzt geht

Nach einer öffentlichen Preview seit Ende Juli gibt es Stacked Pull Requests laut GitHub jetzt auf allen github.com-Plänen. Für GitHub Enterprise Server sind sie für ein kommendes Release angekündigt, eine Versionsnummer nennt GitHub nicht.

Der Weg über die Kommandozeile führt über die Erweiterung gh stack, die unter MIT-Lizenz steht. Der Ablauf, angelehnt an den Quickstart sieht so aus:

gh extension install github/gh-stack

gh stack init                  # Stack beginnen, fragt nach dem ersten Branch
git add .
git commit -m "Datenmodell für Bestellungen"

gh stack add api-endpunkte     # nächste Schicht als neuer Branch
git add .
git commit -m "Endpunkte für Bestellungen"

gh stack submit                # alles pushen, PRs anlegen und verknüpfen
gh stack view                  # Branches, PR-Links und Commits anzeigen

gh stack sync holt später den Stand vom Server, setzt die Schichten bei Bedarf neu auf und pusht in einem Schritt. Habt ihr nach dem Review eine frühere Schicht geändert, zieht gh stack rebase die folgenden nach und hält bei einem Konflikt an, bis ihr ihn gelöst habt. Wer lieber klickt, legt einen zweiten PR an, dessen Ziel der Branch des ersten ist, und wählt dort "Create stack". Bei den Voraussetzungen ist die Doku nicht einheitlich: Der Quickstart verlangt gh ab 2.90.0 und Git ab 2.20, README und CLI-Referenz nennen Git ab 2.36. Mit einem aktuellen Git seid ihr auf der sicheren Seite.

Die Regeln, die im Alltag zählen, stehen in der Referenz:

• Gemergt wird der Reihe nach, die erste Schicht zuerst. Mergen lässt sich der ganze Stack, ein einzelner PR oder eine zusammenhängende Gruppe ab der ersten Schicht. Merge-Commit, Squash und Rebase werden unterstützt.
• Freigaben überleben ein Rebase. Ändert sich der Diff einer Schicht nicht, bleibt die Approval bestehen, auch in Repositories, die veraltete Freigaben sonst verwerfen.
• Branch Protection gilt für jede Schicht. Pflicht-Reviews, Pflicht-Checks und CODEOWNERS werden gegen den Ziel-Branch des Stacks geprüft, nicht gegen die Schicht davor.
• Die Merge Queue behandelt den Stack als Einheit. Fällt ein PR heraus, fallen alle folgenden mit heraus.

Drei Grenzen solltet ihr kennen, bevor ihr das im Team einführt. Alle Branches müssen im selben Repository liegen, Stacks über Forks hinweg gibt es nicht. Auto-Merge für Stacks war am 07.10.2026 noch nicht verfügbar, GitHub rollt es nach eigener Angabe in den nächsten Wochen aus. Und die CI läuft für jede Schicht: Wer teure Pipelines hat, zahlt bei fünf Schichten fünfmal, sofern er die Workflows nicht anpasst.

Agenten in Schichten arbeiten lassen

Für Agenten ist das Werkzeug ausdrücklich mitgedacht. Im selben Repository liegt ein Skill, der dem Agenten die Befehle für nicht-interaktive Läufe beibringt:

gh skill install github/gh-stack

GitHub beschreibt in einem eigenen Tutorial, wie das mit Copilot CLI aussieht: erst einen Schichtenplan vorschlagen lassen, dann Schicht für Schicht umsetzen. Ohne weitere Angabe landet der Skill bei GitHub Copilot. Über die Option --agent lässt er sich laut CLI-Handbuch auch für Claude Code, Cursor oder Codex installieren. Für den Copilot Cloud Agent gilt das nicht automatisch, dessen Doku spricht weiter von einem Pull Request pro Aufgabe.

Entscheidend ist der Auftrag. Ein Agent, der nur "bau die Bestellverwaltung" hört, liefert einen Brocken. Muss er zuerst die Schichten benennen, kommen Teile heraus, die sich einzeln prüfen lassen.

Die 300 Zeilen im Prompt sind die Mitte der Faustregel aus dem ersten Abschnitt. Wichtiger ist der Zwischenstopp: Den Schnitt zwischen den Schichten legt ihr fest, bevor Code entsteht. Das passt zu dem, was wir unter Spec-Driven Development beschrieben haben, nur eine Ebene tiefer.

Nicht auf GitHub? Der Stand bei den anderen

Wer selbst hostet oder aus Gründen der Datenhoheit nicht bei GitHub liegt, hat ebenfalls Möglichkeiten, nur weniger aus einem Guss.

Fehlt die Unterstützung im Server, übernimmt ein lokales Werkzeug die Arbeit. Es merkt sich, welcher Branch auf welchem aufbaut, zieht nach einer Änderung alle Schichten nach und legt die PRs mit dem richtigen Ziel an.

Für ein selbst gehostetes Gitea oder Forgejo sind git-town und git-spice damit die erste Wahl. Beide laufen lokal und brauchen keinen Zusatzdienst. Wer mit Jujutsu oder Sapling arbeitet, kann bestehende Branches auf GitHub nachträglich zu einem Stack verbinden, GitHub dokumentiert das über gh stack link.

Was es kostet

Wer in Schicht 1 nach dem Review etwas ändert, muss alle folgenden Schichten nachziehen. Die Werkzeuge nehmen das Tippen ab, Konflikte löst trotzdem ein Mensch oder ein Agent, und zwar unter Umständen in jeder Schicht einzeln. Dazu kommen die CI-Läufe pro Schicht und eine Lernkurve für alle, die Rebase bisher gemieden haben. Rebase-Aufwand und Lernkurve hat Gergely Orosz schon 2023 aufgelistet, daran ändert auch die Unterstützung im Server nichts.

Nicht jede Änderung braucht einen Stack. Ein Bugfix mit 40 Zeilen wird durch drei Schichten nicht besser. Der Aufwand lohnt sich, wenn eine Änderung mehrere Themen berührt, die sich getrennt beurteilen lassen: Schema, Logik, Oberfläche. Lässt sich so ein Schnitt nicht finden, liegt das meist am Entwurf.

Die Prüfung selbst nimmt euch ein Stack nicht ab, er bringt sie nur auf eine Größe, die sich lesen lässt. Was eine Maschine prüfen kann, gehört weiterhin in automatische Gates, damit im Review die Zeit für das bleibt, was nur Menschen beurteilen.

Was das für dich heißt