GitHub: Stacked Pull Requests sind jetzt allgemein verfügbar

GitHub hat Stacked Pull Requests am 6. Oktober 2026 für alle github.com-Tarife allgemein verfügbar gemacht. Mit einem Stack kann ein Entwickler eine große Änderung in eine Kette kleiner Pull Requests aufteilen, die einzeln geprüft und dann gemeinsam gemergt werden. Die Funktion war seit dem 30. Juli in der Public Preview, und GitHub sagt, dass Teams, die sie nutzen, bereits mehr Code mergen.

Was ein Stacked Pull Request ist

Ein Pull Request (PR) beantragt, einen Branch mit Code in einen anderen zu mergen. Große PRs lassen sich nur langsam prüfen, weil ein Reviewer alles auf einmal verstehen muss.

Ein Stack zerlegt diese Arbeit in Ebenen. Jeder PR zielt auf den Branch darunter, sodass jeder nur seinen eigenen Teil der Änderungen zeigt. Der unterste PR zielt auf den Haupt-Branch, der oft Trunk genannt wird. Laut GitHubs Changelog erhält jede Ebene eigene Reviews und Checks, bevor die Ebenen gemeinsam landen.

Gemergt wird von unten nach oben. CCLeaks, das am 8. Oktober eine Einrichtungsanleitung veröffentlichte, erklärt, dass das Mergen eines PR auch jeden noch nicht gemergten PR darunter landen lässt. Wer den obersten PR mergt, mergt den ganzen Stack. Branch-Regeln gelten weiterhin für jede Ebene, einschließlich Pflicht-Reviews, Status-Checks und Code Owners.

Was sich mit der allgemeinen Verfügbarkeit ändert

Der Changelog vom 6. Oktober nennt diese Änderungen seit der Preview:

Änderung	Was sie bewirkt
Freigaben überstehen Rebases	Ein Rebase des Stacks behält Freigaben für unveränderten Code, auch in Repos, die veraltete Freigaben verwerfen
Signierte Commits	Commits, die bei einem Stack-Rebase neu geschrieben werden, bleiben signiert und behalten ihren ursprünglichen Autor
Merge Queue	Ein Stack kommt als eine Gruppe in die Merge Queue und landet gemeinsam
Merge Commits	Mit der Merge-Commit-Methode erhält jeder PR im Stack seinen eigenen Merge Commit
Gelöschter Basis-Branch	Der Stack wird neu ausgerichtet, statt dass sein unterster PR geschlossen wird
Bypass-Merges	Nutzer, die Repository-Regeln umgehen dürfen, können den untersten nicht gemergten PR mergen

Auto-Merge für Stacks wird laut GitHub noch „in den nächsten Wochen“ ausgerollt. Der PR-Header zeigt jetzt Stack-Details, und die Timeline vermerkt, wann ein PR einem Stack beitritt oder ihn verlässt. Webhooks erhalten eine stacked-Aktion beim pull_request-Event. GitHub Enterprise Server, die selbst gehostete Edition, bekommt Stacks „in einem kommenden Release“.

Die Zahlen, die GitHub nennt

GitHub sagt, Repositories mit Stacks hätten 9 % mehr Code gemergt als vergleichbare Repositories. Außerdem meldet GitHub eine Verbesserung der Zeit bis zum Merge um 5 %. Das sind GitHubs eigene Zahlen, und der Changelog erklärt nicht, wie die Vergleichsgruppe ausgewählt wurde.

Erste Nutzer klingen zufrieden. „Ein einziger Merge mit GitHubs Stacked PRs hat gereicht, damit ich zu dem Schluss kam, dass es großartig ist“, wird Charlie Marsh, der Gründer von Astral, im Changelog zitiert. Im Preview-Beitrag vom Juli sagte Next.js-Lead Tim Neutkens von Vercel: „Wir nutzen GitHub Stacked PRs für Next.js seit einigen Monaten.“

Wie man einen Stack startet

Stacks werden über gh stack gesteuert, eine Erweiterung für die GitHub CLI, das Kommandozeilen-Tool von GitHub. CCLeaks nennt GitHub CLI 2.90.0 oder neuer und Git 2.20 oder neuer als Voraussetzungen. Die GA-Version unterstützt zusätzlich Git-Worktrees, mit denen ein Repository mehrere Branches in getrennten Ordnern ausgecheckt halten kann.

Der grundlegende Ablauf laut der CCLeaks-Anleitung:

1. Die Erweiterung mit gh extension install github/gh-stack installieren.
2. Mit gh stack init einen Stack starten, dann gh stack add <branch> für jede Ebene ausführen.
3. Mit gh stack submit die PRs öffnen und mit gh stack view die Kette ansehen.
4. gh stack rebase ausführen, wenn sich der Basis-Branch bewegt.

Laut dem Preview-Beitrag vom Juli lassen sich Stacks auch auf github.com, in der GitHub-Mobile-App oder von einem Coding-Agenten wie GitHub Copilot mit dem gh-stack-Skill erstellen. In der Web-Ansicht wechseln Shift+J und Shift+K zwischen den PRs eines Stacks.

Grenzen, die man vorher kennen sollte

Die Funktion hat harte Grenzen. CCLeaks nennt diese:

• Nur ein Repository. Jeder Branch muss im selben Repository liegen, Stacks über Forks hinweg funktionieren also nicht.
• Nur gerade Linien. Ein Stack kann sich nicht verzweigen; ein PR kann keine zwei Kinder haben.
• Kein GitHub Desktop. Die Desktop-App unterstützt keine Stacks.
• Alte Merge-Endpunkte scheitern. Ältere PR-Merge-API-Endpunkte können keinen Stack mergen.
• Größere Queue-Gruppen. Die Merge-Queue-Gruppe eines Stacks kann die konfigurierte Maximalgröße um bis zu 50 % überschreiten. Wird ein PR ausgeworfen, fällt auch jeder PR darüber heraus.

Was das für Entwickler bedeutet

Teams, die große Arbeit von Hand in abhängige Branches aufteilen, bekommen jetzt einen eingebauten Ablauf. Vor dem Umstieg lohnt es sich, einige Dinge zu prüfen.

• Automatisierung prüfen. Bots, die über ältere API-Endpunkte mergen, scheitern bei Stacks. Laut CCLeaks erreichen Stack-Daten GitHub Actions als github.event.pull_request.stack, und das Stack-Feld der REST API ist bei einzelnen PRs null. Merge-Bots sollten so angepasst werden, dass sie es auslesen.
• Merge-Queue-Limits überprüfen. Wenn Ihre Queue die Gruppengröße begrenzt, um CI-Kapazität zu schützen, kann ein Stack eine Gruppe um bis zu 50 % über diese Grenze treiben.
• Fork-Beitragende müssen warten. Open-Source-Projekte, die Änderungen aus Forks annehmen, können diese PRs noch nicht stacken.
• Enterprise-Server-Upgrades später planen. Kunden mit selbst gehosteten Instanzen haben kein Datum, nur „ein kommendes Release“.
• Mit einer großen Änderung ausprobieren. Ein Refactoring, das viele Dateien berührt, ist ein naheliegender erster Test. Teilen Sie es in drei oder vier Ebenen auf und prüfen Sie, ob Reviews schneller zurückkommen.

Die 9 % sind GitHubs Aussage über das eigene Produkt. Ihre eigenen Review-Zeiten, vorher und nachher, sind die Zahl, die sich zu verfolgen lohnt.