Gestapelte Pull Requests auf GitHub: kleinere Reviews, ein Merge

Öffne einen Pull Request mit 1.500 geänderten Zeilen und schau zu, was mit ihm passiert. Die Reviewerin liest die ersten Dateien sorgfältig, dann geht der Diff weiter, die Konzentration ist aufgebraucht, und der Rest bekommt ein Scrollen und eine Freigabe. Faul ist dabei niemand. Ein großer Diff verlangt mehr Fokus, als in eine Sitzung passt. Am 6. Oktober 2026 hat GitHub gestapelte Pull Requests (Stacked Pull Requests) allgemein verfügbar gemacht, und genau das ist GitHubs Antwort darauf: eine große Änderung in eine Kette kleiner Pull Requests aufteilen, die jeweils für sich geprüft werden und trotzdem gemeinsam landen.

Warum ein großer Pull Request nur abgenickt wird

Als allgemeine Regel gilt: Die Aufmerksamkeit beim Review sinkt, je größer der Diff wird. Die erste Datei bekommt echte Fragen. Bei der vierzehnten wird nur noch geprüft, ob der Code wie Code aussieht. Der Bug, auf den es ankommt, steckt selten in der Datei, die alle für riskant hielten; er sitzt in einer kleinen Änderung an einem gemeinsam genutzten Helper, auf halber Strecke, wo niemand mehr hinschaute. Auch der Autor zahlt: Eine Beschreibung für 1.500 Zeilen ist schwer zu schreiben, also steht dort meist „siehe Diff“.

Die naheliegende Lösung, kleinere Pull Requests, hatte schon immer ihren Preis. Hängt das zweite Stück vom ersten ab, wartest du entweder, bis das erste gemergt ist, bevor du das zweite öffnest, oder du öffnest sie als Kette und pflegst diese Kette von Hand.

Was ein Stack ist und was die GA geändert hat

Ein Stack ist eine Kette von Branches, in der jeder auf dem vorherigen aufbaut und jeder Branch seinen eigenen Pull Request hat. Der erste fügt eine Migration hinzu, der zweite den Service, der die neue Spalte nutzt, der dritte den Endpoint, der den Service aufruft. Jeder wird unabhängig geprüft, und die Kette wird gemeinsam gemergt.

Das Problem war nie die Idee. Es war das, was passierte, wenn jemand im ersten Pull Request eine Änderung wollte, nachdem der zweite und dritte schon geprüft waren: Jeder Branch darüber musste von Hand rebased werden, und in Repositories, die veraltete Freigaben verwerfen, waren auch die Reviews darüber verloren. GitHubs GA-Release geht genau das an. Die Aktion „Rebase stack“ behält Freigaben für Code, der sich nicht geändert hat, selbst in Repositories, die veraltete Freigaben verwerfen. Rebaste Commits bleiben signiert, weil GitHub signierte Ersatz-Commits erzeugt und den ursprünglichen Autor beibehält.

Der Rest des Releases dreht sich um das Landen des Stacks. Er läuft als eine einzige Merge-Gruppe durch die Merge Queue, und mit der Merge-Commit-Methode erzeugt GitHub einen Merge-Commit pro Pull Request. Bypass-Berechtigungen gelten für den untersten noch nicht gemergten Pull Request im Stack. Verzweigt sich ein Stack und wird sein Basis-Branch gelöscht, werden die Pull Requests darüber automatisch umgehängt, statt dass der unterste geschlossen wird. Auto-Merge für Stacks, bei dem jeder Pull Request einer ausgewählten Gruppe gemergt wird, sobald alle bereit sind, wird in den folgenden Wochen ausgerollt. Zur Orientierung erscheint der Stack im Kopf des Pull Requests, Shift+J und Shift+K springen zwischen seinen Pull Requests, die Timeline vermerkt, wenn einer hinzugefügt oder entfernt wird, der pull_request-Webhook bekommt eine stacked-Aktion, und die Erweiterung gh stack für die GitHub CLI arbeitet mit Git-Worktrees.

GitHub hat außerdem Zahlen aus der Preview-Phase veröffentlicht: Laut GitHub haben Repositories mit Stacks 9 % mehr Code gemergt als vergleichbare, und mehr als zwei Drittel der obersten 1 % der Repositories nutzen inzwischen Stacks und verzeichneten eine um 5 % bessere Time-to-Merge. Lies das als GitHubs Messungen der eigenen Funktion, nicht als unabhängige Studie.

Wenn du der einzige Reviewer bist

Viel Freelance- und Solo-Arbeit hat keinen zweiten Reviewer. Der Stack lohnt sich trotzdem, aus allgemeinen Gründen, die mit GitHubs Zahlen nichts zu tun haben. Den eigenen 200-Zeilen-Diff am nächsten Morgen zu prüfen, findet Dinge, die das Prüfen des eigenen 1.500-Zeilen-Diffs nie finden wird. Einem Kunden lässt sich Schritt zwei lauffähig zeigen, bevor Schritt drei existiert. Wenn einen Monat später etwas kaputtgeht, landet git bisect auf einer kleinen, benannten Änderung statt auf einem riesigen Commit. Und wenn der eigene Entwickler des Kunden das Projekt übernimmt, erbt er eine Historie, die er wirklich lesen kann.

Wann du nicht stapeln solltest

Ein Stack ist Mehraufwand, also sollte er etwas einbringen. Lass ihn weg, wenn die Änderung schon klein genug für ein Review am Stück ist. Lass ihn weg, wenn sich die Teile nicht getrennt beurteilen lassen: Ergibt der erste Pull Request erst nach dem Lesen des dritten Sinn, ist es eine einzige Änderung, und das Aufteilen verteilt die Verwirrung nur auf drei Tabs. Vorsicht, wenn sich der unterste Teil des Stacks noch stark bewegt, denn jede Änderung dort wandert nach oben, und selbst mit erhaltenen Freigaben lesen die Reviewer darüber gegen eine wandernde Basis. Und ein Stack wartet auf seinen untersten Pull Request: In einem Team, in dem Reviews Tage dauern, kann ein fünf Ebenen tiefer Stack länger liegen als ein ehrlicher, mittelgroßer Pull Request.

Wenn ein Branch das nächste Mal ein paar hundert Zeilen überschreitet, halte vor dem Öffnen des Pull Requests an und schreib die Schritte auf, die er tatsächlich gegangen ist. Jeder Schritt, den ein Reviewer allein freigeben könnte, ist ein Pull Request im Stack; der Rest gehört zusammen. Quelle: GitHub Changelog, „Stacked pull requests generally available“ (6. Oktober 2026).