Stacked Pull Requests: 4 Regeln für bessere Reviews

Ein Pull Request mit 94 Dateien, 18.000 Zeilen und dem Kommentar „Bitte einmal kurz drüberschauen“ ist kein Review, sondern eine soziale Zumutung. GitHub versucht dieses Problem jetzt direkt in der Plattform anzugehen: Stacked Pull Requests sind seit dem 30. Juli als Public Preview verfügbar. Große Änderungen werden dabei in kleine, aufeinander aufbauende Pull Requests zerlegt.

Das klingt zunächst nach einer weiteren Git-Funktion für Leute mit drei Monitoren und einer Meinung zu Rebase-Strategien. Der praktische Kern ist aber erfreulich bodenständig: Teams sollen einzelne Teile einer großen Änderung prüfen können, ohne dass die Arbeit an den nächsten Teilen stehen bleibt. Gerade dort, wo KI-gestützte Werkzeuge schneller Code erzeugen, als Menschen ihn sinnvoll lesen können, ist das kein Luxus.

Stacked Pull Requests: Was GitHub jetzt zeigt

GitHub beschreibt einen Stack als geordnete Reihe von Pull Requests. Jeder PR bildet eine klar abgegrenzte Schicht einer Änderung ab und verweist auf die Schicht darunter. Aus einem unübersichtlichen Gesamtpaket kann so etwa erst eine Datenmodell-Änderung, dann die API, danach die Oberfläche und zuletzt die Tests werden. Wer einen Layer prüft, sieht nur dessen Differenz zum unmittelbar vorherigen Layer – nicht den kompletten Berg.

Die Public Preview ist laut GitHubs offiziellem Changelog zur Public Preview in github.com, der GitHub CLI, der mobilen App und in Verbindung mit Coding Agents vorgesehen. Zum Einstieg nennt GitHub die CLI-Erweiterung gh extension install github/gh-stack. Das ist wichtig: Stacks sind nicht bloß ein neues Etikett für mehrere Branches, sondern sollen die vorhandenen Prüfungen, Reviews und Merge-Anforderungen weiterverwenden.

Für Teams ist der Unterschied größer, als er auf den ersten Blick aussieht. Bisher endet ein großer Umbau oft in zwei schlechten Optionen: Entweder ein riesiger PR blockiert die Review-Schlange, oder die Änderungen werden auf getrennte Branches verteilt und müssen ständig manuell nachgezogen werden. Beides kostet Konzentration. Und Konzentration ist beim Code-Review bekanntlich das erste Gut, das nach dem dritten „kleinen“ Nachmittags-PR verschwindet.

Warum kleinere Pull Requests nicht automatisch mehr Arbeit bedeuten

„Dann haben wir eben statt einem PR fünf“ klingt erst einmal nach zusätzlicher Bürokratie. Hand aufs Herz: Fünf sauber umrissene Entscheidungen sind meist leichter zu prüfen als eine einzige Mischkiste aus Refactoring, neuen Endpunkten, Paketupdates und UI-Korrekturen. Die Zahl der Tabs steigt vielleicht. Die geistige Last sinkt aber.

Der Stack macht Abhängigkeiten sichtbar. Ein Review kann beispielsweise nur die Validierung einer neuen Schnittstelle behandeln. Der nächste PR setzt darauf auf und bringt den Client dazu. Der dritte ergänzt Metriken und Tests. Wenn eine Fachperson nur den API-Teil beurteilen kann, muss sie sich nicht durch CSS oder Build-Konfiguration arbeiten. Parallelität entsteht nicht dadurch, dass alle an allem arbeiten, sondern dadurch, dass der Zuschnitt stimmt.

Das passt zu einer Entwicklung, die wir bei digital-magazin.de seit Monaten beobachten: Entwicklerteams kämpfen weniger mit dem bloßen Schreiben von Code als mit der Frage, wie Änderungen nachvollziehbar bleiben. Unser Beitrag über verzögerte Dependabot-Updates gegen Paket-Malware zeigt dieselbe Spannung aus einer anderen Richtung. Geschwindigkeit ohne Prüfpunkte ist keine Produktivität, sondern ein Risiko mit gutem Marketing.

GitHubs eigene Pull-Request-Dokumentation erklärt den Grundmechanismus weiterhin simpel: Ein PR schlägt Änderungen aus einem Branch für die Übernahme in einen anderen vor. Die Referenz zu Pull Requests ist deshalb keine Nebensache. Stacks verändern nicht die Git-Grundidee, sie geben ihr nur eine Struktur, die bei großen Vorhaben nicht sofort zerbröselt.

So arbeiten Stacked Pull Requests im Alltag

Ein realistisches Beispiel: Ein Team modernisiert die Anmeldung einer Webanwendung. PR eins legt neue Datenstrukturen und Migrationen an. PR zwei baut die Serverlogik darauf. PR drei bringt die Ansicht und die Fehlermeldungen. PR vier ergänzt Tests und Telemetrie. Die Reihenfolge ist sichtbar, aber niemand muss warten, bis das gesamte Paket abgeschlossen ist, um den ersten Teil zu prüfen.

Nach der GitHub-Ankündigung lassen sich einzelne Layer unabhängig prüfen und zusammen oder schrittweise mergen. Das kann bei einem dringenden Fix Gold wert sein: Ist die Basisschicht sauber und freigegeben, muss nicht zwingend auf die komfortablere Oberfläche warten. Umgekehrt bleibt eine spätere Schicht klar als Folgearbeit erkennbar. Das wirkt unspektakulär. Es verhindert aber jene Merge-Commits, die später niemand mehr erklären kann.

Ein weiterer Punkt: Branch-Schutzregeln und Checks sollen laut GitHub weiter greifen. Das ist entscheidend. Stacked Pull Requests dürfen kein Hintertürchen sein, über das Teams ihre Qualitätsbarrieren aus Versehen aushebeln. Wer für main Reviews, CI und Freigaben verlangt, sollte diese Regeln pro Schicht sehen – nicht erst, wenn sich mehrere Tage Arbeit zu einem Monster-PR aufgetürmt haben.

KI-Agenten machen den Zuschnitt plötzlich dringend

Die Preview kommt zu einem Zeitpunkt, an dem Coding Agents Aufgaben oft in wenigen Minuten in mehrere Dateien übersetzen. Das ist nützlich, aber es verschiebt den Engpass. Nicht das Erzeugen von Änderungen ist knapp, sondern das fachliche Lesen, Bewerten und Verantworten. Ein großer, von einem Agenten erzeugter PR kann auf den ersten Blick vollständig aussehen und trotzdem an einer kleinen falschen Annahme scheitern.

GitHub nennt ausdrücklich die Arbeit mit Coding Agents als möglichen Weg, Stacks zu nutzen. Daraus folgt kein Freifahrtschein. Im Gegenteil: Wenn ein Agent einen Umbau vorbereitet, sollte der Stack die fachlichen Kontrollpunkte noch deutlicher machen. Datenbankmigrationen, Berechtigungen und externe Schnittstellen verdienen eigene Schichten. Ein Team kann dann prüfen, ob die Annahme stimmt, bevor Folgecode diese Annahme hundertfach weiterträgt.

Das Team von digital-magazin.de testet regelmäßig, wie Governance und Agentenarbeit zusammenpassen. Bei den Governance-Funktionen für GitHub Issues ging es bereits um Zuständigkeiten und Nachvollziehbarkeit. Stacked Pull Requests ergänzen diese Ebene auf der Code-Seite: Nicht nur die Aufgabe, auch die technische Umsetzung bekommt eine lesbare Abfolge.

Meine Einschätzung: Der größte Gewinn liegt nicht im schnellen Merge. Er liegt darin, dass ein Review wieder eine konkrete Frage beantworten kann. Ist diese Migration richtig? Ist diese Berechnung sauber? Hält diese Schnittstelle den Fehlerfall aus? Wer solche Fragen einzeln stellen kann, findet Fehler früher – und muss sie nicht zwischen 16 anderen Änderungen suchen.

Vier Regeln, bevor ein Team Stacks einführt

• Schichten fachlich schneiden: Ein Stack ist keine künstlich zerstückelte To-do-Liste. Jede Ebene braucht eine klare technische Aussage.
• Die Basis klein halten: Wenn der erste Layer schon tausend Zeilen umfasst, ist der Effekt praktisch weg.
• CI je Layer ernst nehmen: Ein grüner Gesamt-Stack hilft wenig, wenn eine Zwischenstufe nie allein funktioniert.
• Merge-Reihenfolge erklären: Die Abhängigkeit muss im Titel und in der Beschreibung verständlich bleiben, auch für Kolleginnen und Kollegen außerhalb des Projekts.

Besonders Open-Source-Projekte können davon profitieren. Dort prüfen häufig Menschen mit begrenzter Zeit und unterschiedlichen Spezialgebieten. Ein kleiner, gut erklärter Teil senkt die Einstiegshürde. Das bedeutet nicht, dass jede Änderung zwingend gestapelt werden muss. Ein einzelner Bugfix bleibt besser ein einzelner Bugfix. Aber bei Umbauten, die mehrere Ebenen berühren, ist der Stack ein brauchbares Gegenmittel gegen Review-Lähmung.

Wo Stacked Pull Requests Grenzen haben

Die Methode löst keine schlechte Architektur. Wenn die Schichten nur deshalb voneinander abhängen, weil ein Team keine klaren Schnittstellen hat, zeigt der Stack dieses Problem eher, als dass er es repariert. Auch Konflikte verschwinden nicht magisch. Ändert ein unterer Layer sich nach dem Review stark, müssen die oberen Teile weiterhin angepasst werden.

Es gibt noch eine organisatorische Falle: Zu feine Stacks können zu einem Ritual werden, bei dem jedes Umbenennen einen eigenen PR erhält. Das hilft niemandem. Die richtige Größe orientiert sich an einer prüfbaren Entscheidung. Wenn ein Reviewer nach zehn Minuten sagen kann „ja, diese Schicht verstehe ich“, ist das ein gutes Zeichen. Wenn erst ein Architekturseminar nötig ist, war der Schnitt vermutlich zu groß.

Wer bei Linux- und Open-Source-Projekten genauer hinsieht, kennt das Spannungsfeld. Auch bei der Debatte, warum GCC den Umgang mit KI-Code begrenzt, geht es am Ende um überprüfbare Herkunft und Verantwortung. GitHub Stacked Pull Requests beantworten nicht jede Lizenz- oder Sicherheitsfrage. Sie können aber die Stelle verkleinern, an der Menschen ihre Verantwortung tatsächlich ausüben.

Der Punkt ist: Review braucht wieder einen Maßstab

GitHub hat mit Stacked Pull Requests keine neue Programmiersprache erfunden. Gut so. Die Public Preview packt ein bekanntes Arbeitsmuster in Werkzeuge, die Teams ohnehin nutzen. Das kann den Unterschied machen, weil jede manuelle Nebenroutine – Branches nachziehen, Vergleichsbasis ändern, Merge-Reihenfolge merken – in der Praxis irgendwann liegen bleibt.

Für Teams mit vielen parallel laufenden Änderungen lohnt sich ein vorsichtiger Test an einem echten Umbau. Nicht am Demo-Repository, sondern bei einer Änderung, die sonst als großer PR gelandet wäre. Messen Sie nicht nur die Zahl der Merges. Fragen Sie die Prüfenden, ob sie schneller verstanden haben, was jede Schicht tut. Wenn die Antwort ja lautet, hat die Preview bereits ihren Zweck erfüllt.

Ein guter Pull Request ist kein Beweis dafür, dass Code perfekt ist. Er gibt anderen Menschen eine faire Chance, Fehler zu entdecken. Genau da liegt der Wert von Stacked Pull Requests. Kleinere Fragen. Klarere Antworten. Weniger Bauchschmerzen vor dem Klick auf „Review anfordern“.

Ein sinnvoller Start für Ihr Repository

Beginnen Sie nicht damit, die komplette Arbeitsweise des Teams umzubauen. Wählen Sie eine Änderung, die ohnehin mehrere Bereiche berührt, aber noch nicht unter Zeitdruck steht. Legen Sie zuerst fest, welche Schicht als tragfähige Basis gelten soll. Danach kommt der nächste Pull Request nur hinzu, wenn er ohne den vorherigen Teil keinen Sinn ergibt. Das klingt banal, zwingt aber zu einer Klarheit, die vielen Repositories fehlt.

Hilfreich ist eine kurze Beschreibung am Anfang jedes Layers: Was ändert sich hier? Wovon hängt dieser Schritt ab? Was soll ein Review konkret prüfen? Drei Sätze reichen meistens. Lange Einleitungen werden selten gelesen; fehlender Kontext rächt sich dagegen zuverlässig. Wer einen Stack übernimmt, sollte außerdem wissen, ob einzelne Layer separat ausgerollt werden können oder ob sie nur gemeinsam funktionieren.

Auch die Benennung verdient Aufmerksamkeit. Titel wie „Teil 2“ helfen niemandem, wenn der ursprüngliche Kontext nach zwei Wochen verschwunden ist. „API: Sitzungsprüfung für neue Anmeldung“ sagt mehr und macht die Review-Zuordnung leichter. Das ist kein Stilfetisch. Bei zehn offenen Pull Requests entscheidet ein guter Titel darüber, ob die passende Person den Vorgang erkennt oder an ihm vorbeiscrollt.

Und noch etwas: Ein abgelehnter unterer Layer ist kein Scheitern des Stacks. Er verhindert gerade, dass fünf Folgeschichten auf einer falschen Entscheidung landen. Das ist der Knackpunkt. Der Aufwand wandert nach vorn, dorthin, wo Korrekturen billig und verständlich sind. Für Softwareteams ist das oft die angenehmste Form von Geschwindigkeit.