DE
Gespräch buchen

Entwicklungsansatz

Gestapelte Pull Requests vs. ein großer Pull Request: Welche Review-Form passt zu KI-generiertem Code?

Gestapelte Pull Requests oder ein großer PR? Reviewgröße, Rebase-Aufwand, signierte Commits und Agentenfähigkeit im Vergleich.

Geprüft von Michael Kerkhoff, Stand

Definition
Programmieragenten haben den Engpass im Review nicht erzeugt, sie haben ihn verschoben. Ein Feature zu schreiben dauert heute Minuten; es zu lesen bedeutet nach wie vor, dass sich ein Mensch mit einem Diff hinsetzt. Das Beispiel aus GitHubs eigenem Beitrag ist deutlich: Ein einziger Prompt für eine Produktsuche liefert Datenmodell, API-Route, Client-Anbindung und vier Zustände der Oberfläche in einem Pull Request mit 1.721 geänderten Zeilen. Die Reaktion des Reviewers in diesem Beitrag — "das schaue ich mir später an" — ist das ganze Problem in fünf Worten. Die Änderung landet nicht deshalb ungeprüft im Hauptzweig, weil jemand nachlässig war, sondern weil das Paket die falsche Form hatte. Gestapelte Pull Requests antworten darauf mit Zerlegung. Statt eines Pull Requests, der alles auf einmal erledigt, liefern Sie eine geordnete Kette, in der jeder Branch auf den darunterliegenden zielt: zuerst die Daten, dann die API, dann die Anbindung, dann die Oberfläche. Jede Ebene ist klein genug, um sie im Kopf zu behalten, jede geht an die Person, die diese Ebene tatsächlich verantwortet, und Ebene eins kann freigegeben werden, während Ebene vier noch entsteht. GitHub hat das nativ ausgeliefert: geschlossene Vorschau am 13. April 2026, öffentliche Vorschau am 30. Juli 2026, dazu eine CLI-Erweiterung gh-stack und eine Agentenfähigkeit, die Programmieragenten beibringt, den Stapel von Anfang an aufzubauen, statt einen fertigen Diff nachträglich zu zerschneiden. Der Preis dafür ist real und gehört nach vorn. Ein Stapel ist eine Abhängigkeitskette, und Abhängigkeitsketten müssen gepflegt werden. Aendern Sie Ebene eins nach dem Review, muss jeder darüberliegende Branch neu aufgesetzt werden. GitHub automatisiert diese Kaskade, doch die Schaltfläche für den Rebase im Browser setzt den Committer zurück und erzeugt unsignierte Commits — was jedes Repository still bricht, das signierte Commits verlangt. Dieser Vergleich bewertet beide Ansätze nach Reviewgröße, Rückmeldezeit, Pflegeaufwand, Merge-Mechanik, Verträglichkeit mit Branch-Schutzregeln und Eignung für Agenten — mit nachprüfbaren Zahlen aus 2026 statt mit Werkstattfolklore.
Kategorie
Entwicklungsansatz
Optionen
Gestapelte Pull RequestsEin einzelner großer Pull Request

Detaillierter Vergleich

Eine Gegenüberstellung der wichtigsten Faktoren für Ihre Entscheidung.

Gestapelte Pull Requests vs Ein einzelner großer Pull Request
FaktorGestapelte Pull RequestsEin einzelner großer Pull Request
Größe der zu prüfenden EinheitJede Ebene betrifft genau ein Anliegen und bleibt im Bereich von 200 bis 400 geänderten Zeilen, in dem das Review nachweislich am wirksamsten ist. GewinnerDas gesamte Feature kommt als ein Diff an; GitHubs Beispiel umfasst vor der Zerlegung 1.721 geänderte Zeilen.
Zuordnung der ReviewerDie Datenebene prüft, wer die Daten verantwortet, die Oberfläche prüft, wer die Oberfläche verantwortet — und die Ebenen lassen sich parallel prüfen. GewinnerEine Person muss Datenmodell, API-Vertrag, Client-Anbindung und Zustände der Oberfläche gleichzeitig im Kopf behalten.
Zeit bis zur RückmeldungEbene eins kann geprüft, korrigiert und freigegeben werden, während Ebene vier noch geschrieben wird. GewinnerNichts ist prüfbar, bevor das ganze Feature fertig ist — alle Rückmeldungen kommen erst am Schluss.
Aufwand bei Änderungen an einer unteren EbeneEine Korrektur unten erzwingt ein kaskadierendes Neuaufsetzen aller darüberliegenden Branches; gh stack sync automatisiert die Kaskade, der Rebase bleibt aber echte Arbeit.Ein Branch, ein Rebase, keine Abhängigkeitskette, die nach einer Rückmeldung repariert werden muss. Gewinner
Merge-MechanikDer gesamte Stapel lässt sich in einem Schritt zusammenführen, oder Sie führen untere Ebenen ein und die darüberliegenden Pull Requests setzen sich automatisch neu auf.Ein einzelner Merge ohne Stapelzustand und ohne Entscheidungen über Teil-Übernahmen.
Signierte Commits und Branch-SchutzregelnDie Schaltfläche für den Rebase im Browser läuft auf GitHubs Servern, setzt den Committer zurück und erzeugt unsignierte Commits, was den Schutz für signierte Commits bricht; gh stack rebase lokal vermeidet das.Keine kaskadierenden Rebases, also kein zurückgesetzter Committer und keine verlorene Signatur. Gewinner
Obergrenze der SkalierungAus der Praxis werden drei bis vier Ebenen als sinnvolle Grenze berichtet; darüber wiegt das Nachhalten der Abhängigkeiten schwerer als der Reviewgewinn.Keine strukturelle Größengrenze, aber Reviewqualität und Aufmerksamkeit lassen mit wachsendem Diff nach.
Eignung für ProgrammieragentenDie Agentenfähigkeit von gh-stack bringt Agenten bei, die Arbeit schon beim Schreiben in geordnete Ebenen zu zerlegen — die Form wird zur Vorgabe statt zur Nacharbeit. GewinnerAuf zehn Jahre monolithischer Pull Requests trainierte Agenten liefern standardmäßig einen großen Diff, und diesen nachträglich zu zerschneiden ist mühsamer, als gleich in Ebenen zu bauen.
Gesamtpunktzahl · 2 unentschieden4 / 82 / 8

Wichtige Statistiken

Echte Daten aus verifizierten Branchenquellen zur Unterstützung Ihrer Entscheidung.

  • GitHubs Beispiel bündelt Datenmodell, API-Route, Client-Anbindung und vier Zustände der Oberfläche in einem einzigen Pull Request mit 1.721 geänderten Zeilen, bevor er in vier gestapelte Ebenen zerlegt wird. — GitHub Engineering Blog (2026)
  • Eine bei der Ankündigung zitierte Auswertung von 1,5 Millionen Pull Requests ergab: Pull Requests mit 200 bis 400 geänderten Zeilen enthielten 40 Prozent weniger Fehler und wurden dreimal schneller freigegeben als größere. — InfoQ (2026)
  • Gartner erwartet, dass Programmieragenten bis 2028 in jeder Phase des Softwarelebenszyklus einen Produktivitätsgewinn von 50 Prozent bringen — und damit häufiger große Diffs zum Review anliefern. — Gartner, zitiert von GitHub Engineering (2026)
  • GitHubs CLI-Erweiterung gh-stack erreichte 1.093 Sterne und ihre erste getaggte Veröffentlichung v0.1.0 am 29. Juli 2026 — einen Tag vor dem Start der öffentlichen Vorschau gestapelter Pull Requests. — GitHub REST API, github/gh-stack (2026)
  • Gestapelte Pull Requests gingen am 13. April 2026 in die geschlossene und am 30. Juli 2026 in die öffentliche Vorschau; die Ankündigung der öffentlichen Vorschau erreichte 780 Punkte auf Hacker News. — GitHub Changelog (2026)
  • Aus der Praxis werden drei bis vier Pull Requests je Stapel als sinnvolle Obergrenze berichtet; darüber wiegt der gedankliche Aufwand für das Nachhalten der Abhängigkeiten schwerer als der Reviewgewinn. — Alan West, zitiert von InfoQ (2026)

Alle Statistiken stammen aus verifizierten Drittquellen. Quelle, Jahr und Original-Link werden direkt bei jeder Kennzahl angezeigt.

Wann Sie welche Option wählen sollten

Klare Orientierung basierend auf Ihrer spezifischen Situation und Ihren Bedürfnissen.

Unsere Empfehlung

Wählen Sie gestapelte Pull Requests, wenn die Reviewkapazität Ihr Engpass ist und die Änderung natürliche Ebenen hat. Das ist inzwischen der Normalfall: Der Technikchef von TED beschreibt genau dieses Muster in GitHubs Ankündigung — KI habe die Entwicklerinnen und Entwickler deutlich produktiver gemacht, und der neue Engpass seien Pull Requests, die so groß wurden, dass die Reviewer ins Straucheln gerieten. Die Datenlage stützt die kleinere Einheit: Eine bei der Ankündigung zitierte Auswertung von 1,5 Millionen Pull Requests ergab, dass Pull Requests mit 200 bis 400 geänderten Zeilen 40 Prozent weniger Fehler enthielten und dreimal schneller freigegeben wurden als größere. Ein Stapel ist genau der Mechanismus, der einzelne Pull Requests in diesem Korridor hält, auch wenn das Feature umfangreich ist. Wählen Sie einen einzelnen Pull Request, wenn die Änderung wirklich nur ein Anliegen betrifft, wenn Ihr Repository signierte Commits verlangt und Ihr Team den lokalen Weg über gh stack rebase nicht zuverlässig geht, oder wenn das Feature mehr als drei bis vier Ebenen bräuchte. Diese Grenze ist nicht willkürlich: Aus der Praxis werden drei bis vier Pull Requests pro Stapel berichtet, darüber kostet das Nachhalten der Abhängigkeiten mehr Aufmerksamkeit, als die kleineren Diffs einsparen. Ein fünfstufiger Stapel, den niemand sauber neu aufsetzt, ist schlechter als ein ehrlicher großer Diff. Entscheidend ist am Ende nicht die Reife der Werkzeuge, sondern wer den Code schreibt. Ein Agent, der auf zehn Jahre monolithischer Pull Requests trainiert wurde, liefert einen monolithischen Pull Request, solange Sie nichts anderes vorgeben — und einen fertigen Diff mit 1.700 Zeilen nachträglich in Ebenen zu zerlegen ist deutlich mühsamer, als ihn gleich in Ebenen zu bauen. Installieren Sie die Agentenfähigkeit, geben Sie jeder Ebene einen klar umrissenen Umfang und eine verantwortliche Person, dann geschieht die Zerlegung beim Schreiben, wo sie billig ist. Lassen Sie diesen Schritt aus, sind gestapelte Pull Requests nur zusätzliche Branches, die neu aufgesetzt werden müssen. Die Review-Form muss eine Vorgabe an den Agenten sein, keine Aufräumarbeit für den Menschen.

Wählen Sie Gestapelte Pull Requests, wenn...
  • Die Änderung zerfällt natürlich in abhängige Ebenen — Daten, API, Anbindung, Oberfläche — mit jeweils eigenen Verantwortlichen.
  • Ein Programmieragent hat einen Diff geliefert, den Sie in einer Sitzung nicht ehrlich prüfen können.
  • Ihr Engpass ist die Reviewkapazität, nicht die Geschwindigkeit beim Schreiben.
  • Die Grundebene soll geprüft und übernommen werden, während die darüberliegenden Ebenen noch entstehen.
Wählen Sie Ein einzelner großer Pull Request, wenn...
  • Die Änderung betrifft wirklich nur ein Anliegen und bleibt bei wenigen hundert geänderten Zeilen.
  • Ihr Repository verlangt signierte Commits und das Team geht den lokalen Weg über gh stack rebase nicht zuverlässig.
  • Das Feature bräuchte mehr als drei bis vier Ebenen, wo der Abhängigkeitsaufwand den Reviewgewinn übersteigt.
  • Ihr Team hat keine stapelfähigen Werkzeuge und müsste die Branch-Kette von Hand pflegen.

Häufige Fragen zu diesem Vergleich beantwortet.

Häufig gestellte Fragen

(01)Was sind gestapelte Pull Requests?
Gestapelte Pull Requests sind eine geordnete Kette, in der jeder Branch nicht auf den Hauptzweig zielt, sondern auf den unmittelbar darunterliegenden. Ein Feature wird so zu einer Folge kleiner, unabhängig prüfbarer Ebenen — etwa Datenmodell, dann API-Endpunkt, dann Client-Anbindung, dann Oberfläche. GitHub hat das 2026 nativ umgesetzt: geschlossene Vorschau am 13. April, öffentliche Vorschau am 30. Juli, dazu die CLI-Erweiterung gh-stack, eine Stapelübersicht im Pull Request und das Zusammenführen des ganzen Stapels mit einem Klick.
(02)Funktionieren gestapelte Pull Requests mit bestehenden Branch-Schutzregeln und CI?
Ja. Prüfungen und Merge-Regeln werden gegen die Basis des Stapels ausgewertet, nicht gegen den unmittelbaren Vorgänger des jeweiligen Branches. Die CI läuft auf jeder Ebene so, als zielte sie direkt auf den Hauptzweig, und bestehende Schutzregeln bestimmen weiterhin, was in den Hauptzweig gelangt. Ein Vorbehalt ist wichtig: Die Schaltfläche für den Rebase im Browser läuft auf GitHubs Servern, setzt dabei den Committer zurück und erzeugt unsignierte Commits. Wenn Ihre Schutzregeln signierte Commits verlangen, nutzen Sie stattdessen lokal gh stack rebase und danach gh stack push.
(03)Warum liefern Programmieragenten standardmäßig einen einzigen riesigen Pull Request?
Weil die Trainingsdaten so aussehen. Agenten haben aus zehn Jahren Pull Requests gelernt, in denen ein ganzes Feature in einem Diff landete — ein Prompt ergibt also eine große Änderung. Der Ausweg besteht darin, die Review-Form zum Bestandteil der Anweisung zu machen statt zur Nacharbeit: Mit der installierten Agentenfähigkeit von gh-stack lernen passende Agenten, einen Stapel anzulegen, jede Ebene auf der darunterliegenden aufzusetzen und erst zu committen, wenn die Prüfungen grün sind. Die Zerlegung passiert dann während des Schreibens, nicht danach.
(04)Wie viele Ebenen sollte ein Stapel haben?
Drei bis vier gelten in der Praxis als sinnvolle Obergrenze; darüber wiegt der gedankliche Aufwand für die Abhängigkeiten schwerer als der Reviewgewinn. Streben Sie Ebenen an, die jeweils genau eine Sache erledigen und im Bereich von 200 bis 400 geänderten Zeilen liegen — dort fand eine Auswertung von 1,5 Millionen Pull Requests 40 Prozent weniger Fehler und dreimal schnellere Freigaben. Wenn ein Feature sechs oder sieben Ebenen bräuchte, ist das meist ein Hinweis, es als zwei getrennte Features auszuliefern statt als einen sehr hohen Stapel.

Brauchen Sie Hilfe bei der Entscheidung?

Buchen Sie ein kostenloses 30-minütiges Beratungsgespräch und wir helfen Ihnen, den besten Ansatz für Ihr Projekt zu bestimmen.

Kostenloses BeratungsgesprächE-Mail senden

Kostenlose Beratung · Unverbindlich · Persönliche Antwort