Am 6. Oktober 2026 kündigte GitHub die allgemeine Verfügbarkeit von gestapelten Pull Requests (stacked pull requests) an. Die Funktion erlaubt es, eine große Änderung in mehrere kleinere Pull Requests aufzuteilen, die unabhängig geprüft und gemeinsam zusammengeführt werden können. Die Funktion befand sich seit dem 30. Juli 2026 in der öffentlichen Vorschau; sie ist nun in allen github.com-Tarifen verfügbar, eine Version für GitHub Enterprise Server wurde ohne genaues Datum angekündigt.
Was die Vorschauphase zeigte
Während der Vorschau führten laut GitHub Repositories, die Stacks nutzen, 9 % mehr Code zusammen als vergleichbare Repositories, bei einer um 5 % verkürzten Zeit bis zum Merge. Mehr als zwei Drittel der aktivsten 1 % der GitHub-Repositories nutzen den Mechanismus bereits – ein Hinweis auf die Akzeptanz bei Teams mit hohem Beitragsvolumen.
Zusammenführen und Rebase: die eigentliche Änderung
Der Schritt zur allgemeinen Verfügbarkeit betrifft vor allem die Merge-Mechanik. Der Befehl rebase stack erhält nun bereits erteilte Freigaben für unveränderten Code, selbst in Repositories, die bei jedem neuen Commit veraltete Freigaben verwerfen. Rebasete Commits bleiben signiert, wenn Branch-Regeln dies verlangen oder die ursprünglichen Commits signiert waren, und die ursprüngliche Autorenschaft bleibt erhalten.
Ein Stack tritt als einzelne Merge-Gruppe in die Merge-Queue ein und durchläuft sie auch so: Bei der Merge-Commit-Methode erstellt GitHub einen Merge-Commit pro Pull Request. Wird der Basis-Branch eines Stacks gelöscht, wird der Stack automatisch neu ausgerichtet, anstatt seinen untersten Pull Request zu schließen, was Stacks ermöglicht, die von anderen Stacks abzweigen.
| Aspekt | Vorher (Vorschau) | Bei allgemeiner Verfügbarkeit |
|---|---|---|
| Rebase | Machte Freigaben ungültig | Erhält Freigaben für unveränderten Code |
| Zusammenführen | Pull Request für Pull Request | Einzelne Merge-Gruppe über die Merge-Queue |
| Gelöschter Basis-Branch | Unterster Pull Request wurde geschlossen | Stack wird automatisch neu ausgerichtet |
| Automatisches Zusammenführen | Nicht verfügbar | Schrittweiser Rollout über mehrere Wochen |
Navigation und Automatisierung
Stack-Informationen erscheinen jetzt im festen Header der Pull-Request-Seite und in der Liste der Pull Requests. Die Tastenkombinationen Shift+J und Shift+K erlauben das Wechseln zwischen Pull Requests desselben Stacks, und die Timeline zeigt an, wann ein Pull Request einem Stack beitritt oder ihn verlässt. Der pull_request-Webhook stellt nun eine stacked-Aktion bereit, wenn ein Pull Request einem Stack beitritt – zum Beispiel um die Caching-Strategie von GitHub-Actions-Workflows danach auszurichten, ob ein Pull Request zu einem Stack gehört oder nicht.
Die CLI-Erweiterung gh stack unterstützt nun Git-Worktrees und bietet eine schnellere Initialisierung, Checkout und Navigation. Ein Entwickler, der mehrere Stacks parallel bearbeitet, braucht dafür keine mehrfachen Clones mehr.
gh stack create feature/refonte-auth
gh stack push
gh stack sync # rebase + mise à jour de la stack entière
gh stack ls # liste les PR de la stack courante
Mehr als zwei Drittel der aktivsten 1 % der GitHub-Repositories nutzen bereits gestapelte Pull Requests.
Das automatische Zusammenführen von Stacks wird schrittweise über mehrere Wochen ausgerollt: Ein Team, das es in seinen Repository-Einstellungen noch nicht sieht, muss auf seiner Seite nichts konfigurieren – es handelt sich um einen Rollout seitens GitHub.
Für Teams, die Pull Requests bereits manuell stapeln
Teams, die ihre Pull Requests bereits manuell gestapelt haben, über Namenskonventionen oder Drittanbieter-Tools, können migrieren, ohne ihre Arbeitsweise zu ändern: Die gleichen CLI-Gewohnheiten bleiben gültig, GitHub fügt die Merge-Mechanik lediglich hinzu. Der Hauptvorteil bleibt die Review-Qualität: Ein 2000-Zeilen-Pull-Request wird zu fünf 400-Zeilen-Pull-Requests, jeder mit eigenem Review-Kontext.
Das Wichtigste in Kürze
Gestapelte Pull Requests verlassen die Vorschau mit einer robusteren Merge-Mechanik: erhaltene Freigaben beim Rebase, gruppierte Zusammenführungen über die Merge-Queue und eine schnellere CLI-Erweiterung. Die Funktion ist ab heute in allen github.com-Tarifen verfügbar, ohne dass Repositories, die sie noch nicht nutzen, etwas unternehmen müssen.
Stacks lösen ein echtes Code-Review-Problem, verlangen aber eine Disziplin, die viele Teams noch nicht haben: Ändert sich ein Pull Request in der Mitte eines Stacks nach einer Review grundlegend, muss alles Nachfolgende rebaset werden – und genau dort zeigt sich, ob GitHubs automatisches Rebasing wirklich hält, was es verspricht. Es lohnt sich, das zu testen, bevor man es zur Teamkonvention macht. — Simon Janvier
Zum Weiterlesen: die offizielle Ankündigung im GitHub-Changelog.
