Stacked PRs sind jetzt Mainstream auf GitHub. Hier ist Ihr Rollout‑Plan.

Sie haben kein Geschwindigkeitsproblem. Sie haben ein Batching‑Problem. GitHub hat gerade die letzte Ausrede entfernt: Stacked Pull Requests sind jetzt ein First‑Class‑Workflow. Wenn Ihr Team Arbeit weiterhin in 1.500‑Zeilen‑Mega‑PRs „wegen des Kontexts“ bewegt, zahlen Sie eine versteckte Steuer in Form von Review‑Latenz, Merge‑Konflikten und Freitagabend‑Rollbacks. Stacked PRs sind der Weg, wie Meta, Google und Graphite‑ähnliche Teams seit Jahren sicher bei hoher Geschwindigkeit ausliefern. Jetzt können Sie das auch – ohne GitHub zu verlassen.

Was „Stacked PRs“ tatsächlich ändern

Stacked PRs erlauben es, eine Sequenz kleiner, abhängiger Änderungen als einzeln prüfbare Einheiten zu landen, die in Reihenfolge mergen. Jeder PR basiert auf dem vorherigen, sodass Sie ein Feature in fünf 150‑Zeilen‑Schritten statt in einem 750‑Zeilen‑Klippen‑Sprung shippen. Reviewer sehen saubere Diffs; die CI validiert jeden Schritt; Reverts sind chirurgisch. Das ist keine Nettigkeit. Es ist ein starker Hebel, um Batching zu eliminieren und die Change‑Failure‑Rate zu senken – bei gleichzeitig hohem Durchsatz.

Warum jetzt? Weil GitHub den Glue‑Code entfernt hat. Sie brauchen keine maßgeschneiderten Skripte oder Dritttools mehr, um abhängige Branches zu managen, Bases umzuhängen und in Reihenfolge zu mergen. Mit nativen Stacked PRs plus Merge‑Queues bekommen Sie lineare History, automatisches Rebase und Checks pro PR – ohne Sonderaktionen.

Wann Stacked PRs helfen (und wann nicht)

• Sie helfen, wenn Sie ein Monorepo, starke Kopplung oder häufige Querschnittsänderungen haben (Framework‑Upgrades, API‑Migrationen, UI‑Refactors). Rechnen Sie mit 25–40% geringerer medianer Time‑to‑Merge und weniger „Review‑Resets“ durch Drive‑by‑Konflikte.
• Sie helfen, wenn AI‑unterstütztes Coding das Änderungsvolumen aufbläst. LLMs fassen gern fünf Dateien für eine „einfache“ Anpassung an. Stacking isoliert Tool‑Churn von Verhaltensänderungen.
• Sie helfen nicht, wenn Ihre CI‑Kosten linear mit der PR‑Anzahl steigen und Ihnen Build‑Graph‑Invalidierung fehlt. Wenn jeder PR einen zweistündigen Monorepo‑Rebuild auslöst, schmilzt Ihre Queue.
• Sie helfen nicht bei trivialen Änderungen oder Ein‑Datei‑Edits. Fügen Sie einer Einzeiler‑Änderung keine Zeremonie hinzu.

Faustregel: Wenn eine Änderung vernünftigerweise in zwei fokussierten Sitzungen reviewbar wäre, dann splitten. Zielen Sie auf 100–300 LOC pro PR mit genau einem Thema pro Diff. Über 400 LOC bläht sich Ihre p95‑Review‑Zeit auf und die Vorteile verfallen.

Ein 30‑Tage‑Rollout‑Plan für CTOs

Woche 1: Die Rahmenbedingungen festlegen

1. Wählen Sie ein Pilotteam mit 5–10 Engineers in einem Bereich des Monorepos mit hoher Änderungsrate. Meiden Sie im ersten Monat das Infra‑Team, das globale Build‑Dateien besitzt.
2. Definieren Sie Ihre History‑Policy: Rebase/Merge‑Queue + lineare History. Aktivieren Sie GitHubs Merge‑Queue für den Default‑Branch und verlangen Sie Status‑Checks. Das liefert deterministische Reihenfolge und weniger „vergifteten Trunk“‑Vorfälle.
3. Legen Sie Ihr Stack‑Budget fest: begrenzen Sie Stacks auf 3–5 PRs. Über 7 verlieren Reviewer den Kontext und Sie rekonstruieren Batching durch die Hintertür.
4. Setzen Sie Reviewer‑SLAs: 24 Geschäfts­stunden bis zur ersten Reaktion; 48 Stunden bis zur Freigabe auf Grün. Veröffentlichen Sie das so sichtbar wie Ihre On‑Call‑Rotationen.
5. Instrumentieren Sie Basis‑Metriken: mediane PR‑Größe (LOC), Time‑to‑First‑Review, Time‑to‑Merge, Change‑Failure‑Rate (Hotfixes innerhalb von 72 Stunden nach Merge) und konfliktbedingte Nacharbeit. Wenn Sie das heute nicht messen, wissen Sie nicht, ob Stacking sich auszahlt.

Woche 2: Leitplanken im Code, nicht in Confluence

1. Branch‑Benennung: erzwingen Sie ein Muster wie user/feature‑id/stack‑01, stack‑02 usw. Ihre CI kann das aufgreifen, um Stacks zu visualisieren und zu regeln.
2. Commit‑Disziplin: jeder Stacked PR braucht einen klaren Zweck‑Satz in der Beschreibung: „Stack 2/4: Validierungsschicht extrahieren; keine Verhaltensänderung.“ Fügen Sie eine explizite Reviewer‑Checkliste hinzu (Tests, Migrationen, Flags). Disziplin schlägt Bauchgefühl.
3. CODEOWNERS in der richtigen Granularität: verteilen Sie die Review‑Last. In einem Monorepo sterben zu viele Stacks am Altar von „die eine Person, die /core/ freigeben kann“. Brechen Sie Ownership möglichst nach Verzeichnis oder Sprachoberfläche auf.
4. Stack‑fähige CI: führen Sie schnelle Checks auf jedem PR im Stack aus (Lint, Unit‑Tests, Typprüfungen) und reservieren Sie vollständige e2e‑Suiten für die Stack‑Spitze oder das Merge‑Queue‑Gate. Fügen Sie einen „revalidate top“‑Job hinzu, der automatisch läuft, wenn sich ein unterer PR ändert.
5. Automatisches Base‑Updating: aktivieren Sie automatisches Base‑Retargeting und Rebase on Merge in GitHub. Menschen sollten das nicht anfassen. Der Stack soll ohne manuelle Pushes „nach vorne ripplen“.

Woche 3: Pilot unter Realbedingungen

1. Wählen Sie ein echtes Feature mit sichtbarem Wert und bekannten Querschnittsedits (z. B. Austausch einer Logging‑Library, Hinzufügen von Audit‑Events oder Anheben einer Service‑Grenze).
2. Designen Sie den Stack vor dem Coden. Fünf Karten auf einem Board: 1) reine Extraktion, 2) Adapter und Shims, 3) Migrations‑Write‑Path hinter einem Flag, 4) Read‑Path‑Flip hinter einem Flag, 5) Dead‑Code‑Entfernung und Clean‑up. Shippen Sie jeden Schritt als eigenen PR.
3. Nutzen Sie Feature‑Flags und Migrations‑Guards: jede Verhaltensänderung landet dunkel. Jeder PR muss sicher sein, eigenständig gemergt und reverted zu werden.
4. Schalten Sie Auto‑Merge für grüne PRs ein, damit niemand auf Buttons campen muss. Lassen Sie die Merge‑Queue das Landen serialisieren.
5. Erzwingen Sie einen Revert‑Plan: üben Sie eine „Revert‑Range“‑Drill. Wenn PR 3 nach Merge fehlschlägt, revertieren Sie nur 3. Wenn ein Rollback das Zurückdrehen von 1–3 erfordert, sind Ihre Stack‑Grenzen falsch.

Woche 4: Messen und ausrollen

1. Vergleichen Sie die Metriken: Ziel sind 25–40% schnellere mediane Time‑to‑Merge, 30–50% kleinere Diffs und ein Rückgang konfliktgetriebener Nacharbeit um die Hälfte. CI‑Kosten können um 10–25% steigen, sofern Sie Build‑Invalidierung nicht getuned haben.
2. Kodifizieren Sie Regeln in einem kurzen Guide: 1–2 Themensätze pro PR, 100–300 LOC, alles unter Flags, Stack‑Cap bei 5. Fügen Sie einen Abschnitt „Wann nicht stacken“ hinzu.
3. Rollen Sie auf angrenzende Teams aus, aber koppeln Sie das an die CI‑Gesundheit. Wenn die Merge‑Queue‑Wartezeit in der Spitze > 30 Minuten liegt oder e2e‑Flakes auf der Queue > 2% sind, fixen Sie die Infra, bevor Sie weitere Stacks hinzufügen.

Monorepo‑Realität: Bringen Sie die CI nicht in die Knie

Der schnellste Weg, einen Stacked‑PR‑Rollout zu verderben, ist, die Pipelines zu sprengen. Ein Monorepo, das pro PR „die Welt“ neu baut, macht kleine Diffs zu großen Rechnungen. Fixen Sie das zuerst:

• Build‑Graph‑Invalidierung: setzen Sie auf ein Build‑System, das Targets und Abhängigkeiten versteht (Bazel, Buck2, Gradle mit Remote‑Cache, Turborepo). Wenn ein reiner UI‑PR eine Backend‑e2e‑Suite triggert, verbrennen Sie Geld.
• Aggressiv cachen: aktivieren Sie Remote‑Caching und die Wiederverwendung des GitHub Actions cache über gestapelte Branches hinweg. Stacks teilen sich die meisten Artefakte.
• Checks aufteilen: schnelle Checks (unter 5 Minuten) auf jedem PR im Stack; langsame Suiten nur an der Spitze und am Merge‑Queue‑Gate. Allein das senkt CI‑Minuten in Piloten, die wir gesehen haben, um 20–30%.
• Pre‑Merge‑Integration: nutzen Sie GitHubs Merge‑Queue als Source of Truth. Rebasen Sie jeden PR auf den Queue‑Head, führen Sie die vollen Gates einmal aus und landen Sie dann in Reihenfolge. Das ist Ihr „Integrationstest“, nicht jeder PR.

Review‑Ergonomie: Schonen Sie Ihre Menschen

Stacked PRs können Reviewer verbrennen, wenn Sie unachtsam sind. Tools sind wichtig, Gewohnheiten sind wichtiger.

• Stack begrenzen: keine „Infinite‑Scroll“‑Stacks. Wenn neuer Scope auftaucht, landen Sie den aktuellen Stack und öffnen Sie eine neue Sequenz. Halten Sie eine Kette nicht wegen Erkenntnissen aus Woche zwei als Geisel.
• Ein Anliegen pro PR: „Rename + Logikänderung“ sind zwei PRs. Namespaces, Imports, Renames zuerst. Verhalten später. Ihr zukünftiges Ich wird es Ihnen beim Revert danken.
• Diff‑Hygiene: kennzeichnen Sie Refactor‑Only‑PRs mit „keine Verhaltensänderung“ und setzen Sie es durch. Blockieren Sie Teständerungen, die Logik einschmuggeln.
• Reviewer nach Schicht zuweisen: spezialisierte Augen für Refactors vs. Verhaltensänderungen. Der Data‑Migration‑PR geht an die DB‑Owner. Der Adapter‑PR an Platform. Sprühen Sie keine Anfragen an fünf Leute für jede Schicht.
• Review‑Budgets: maximal 45 Minuten pro Tag für Reviews. Wenn ein Stack das Budget übersteigt, ist er zu groß oder falsch geschnitten. Schützen Sie Fokus.

Schema‑Änderungen und andere harte Themen

Stacked PRs glänzen bei Migrationen – wenn Sie Reihenfolge und Sicherheit respektieren.

• Expand–Migrate–Contract: PR1 fügt neue nullable Spalten hinzu + Dual‑Write hinter einem Flag; PR2 backfillt mit idempotenten Jobs; PR3 dreht Reads um; PR4 löscht alte Spalten. Jeder PR ist sicher und unabhängig revertierbar.
• Runtime‑Gates: shippen Sie Migrationen mit Kill‑Switches (Feature‑Flags, Environment‑Toggles). Wenn Ihr Rollback‑Plan „aus Backup wiederherstellen“ heißt, haben Sie keinen Plan.
• Data‑Access‑Shims: fügen Sie in frühen PRs Lese/Schreib‑Adapter hinzu, sodass spätere PRs die Persistenz ändern können, ohne Call‑Sites anzufassen. Das reduziert Blast‑Radius und Review‑Umfang.
• Cross‑Repo‑Kanten: wenn Ihre Verträge Repos überspannen, frieren Sie Interfaces über versionierte Clients ein. Landen Sie Server‑Stacks zuerst, dann Client‑Stacks hinter Toggles. Verflechten Sie keine Server/Client‑PRs in einer einzigen Abhängigkeitskette über Repos hinweg.

AI‑unterstützte Teams: Churn eindämmen

AI beschleunigt das Tippen, nicht die Integration. Stacked PRs sind Ihr Regler.

• Verlangen Sie einen „Spec PR“ am unteren Ende jeder mehrdateiigen AI‑Änderung: nur Tests, Typen und Interface‑Skizzen; kein Verhalten. Danach lässt man AI die Implementierungen in den oberen Schichten ausfüllen. Reviewer können den Vertrag einmalig abnehmen.
• Diff‑Linting: blockieren Sie PRs, die LOC‑Caps überschreiten, außer sie sind als „Migration“ getaggt. AI überschießt gern; erzwingen Sie Disziplin automatisch.
• Tool‑Fingerprints: führen Sie statische Analyse‑(SARIF)‑Diffs auf jeder PR‑Schicht aus. Manche quantisierten Modelle verschlechtern die Zuverlässigkeit von Tool‑Calls; schichten Sie kleine Änderungen, um Ausfälle sichtbar zu machen.

Governance und Risiko

Stacking ist kein Freifahrtschein. Behandeln Sie es wie jede Prozessänderung: Kontrollen definieren, dann messen.

• Sicherheits‑Scans pro Schicht: Code‑Scanning sollte auf jedem PR laufen, auch bei Refactors. So fangen Sie „harmlose“ mechanische Änderungen ab, die versehentlich die Angriffsfläche vergrößern.
• Ownership‑Grenzen: verlangen Sie explizite Freigaben, wenn ein PR eine Hochrisiko‑Grenze überschreitet (Auth, Billing, PII). Lassen Sie einen Low‑Risk‑Refactor nicht in sensiblen Code abdriften.
• Deployment‑Sicherheit: koppeln Sie Feature‑Flags an berechtigte Togglers. Wenn jeder einen halb gelandeten Stack in Prod einschalten kann, haben Sie „groß mergen, beten“ mit Runbooks neu erfunden.
• Incident‑Response: führen Sie eine „Revert‑First“‑Policy ein und feiern Sie Reverts. Ein klarer Revert auf PR 3/5 ist ein Erfolg, kein Scheitern. Belohnen Sie Geschwindigkeit und Klarheit.

Zahlen, die Sie vor Ihrem CFO vertreten können

Es gibt Trade‑offs, aber die Rechnung geht meist auf:

• Throughput: Teams, die von 800–1.200‑LOC‑PRs auf 150–300‑LOC‑Stacked‑Diffs umstellen, sehen typischerweise innerhalb von zwei Sprints 25–40% niedrigere mediane Time‑to‑Merge. Reviewer entscheiden schneller mit weniger Kontextwechseln.
• Rework: konfliktgetriebene Nacharbeit sinkt um 40–60%, weil die Merge‑Reihenfolge deterministisch ist und Rebasings automatisch laufen. Das reduziert auch Wochenend‑„Feuerübungen“.
• CI‑Kosten: ohne Build‑Invalidierung können CI‑Minuten um 10–25% steigen. Mit targetbasierten Builds und Cache‑Wiederverwendung haben wir in Piloten netto neutral oder sogar –10% gesehen, weil Flakes und Retries fielen.
• Change‑Failure‑Rate: kleine Diffs plus Flags senken Post‑Merge‑Incidents um 15–30%. Reverts sind günstiger und weniger politisch; Leute ziehen früher die Reißleine.

Dafür braucht es keinen Glauben. Erheben Sie DORA‑Metriken und einen Konflikt‑Zähler. Wenn Ihr Stack diese nicht bewegt, stoppen Sie und fixen Sie Scope‑Kontrolle oder CI – und versuchen Sie es dann erneut.

Häufige Fehlermuster (und wie man sie vermeidet)

• Die endlose Treppe: Stacks, die nie landen, weil untere Schichten sich ständig ändern. Fix: Stack‑Höhe kappen und abgeschlossene Sequenzen wöchentlich mergen, auch wenn das Feature noch nicht „fertig“ ist. Flags gibt es aus einem Grund.
• Review‑Stampeden: jede Schicht pingt die gleichen drei Personen. Fix: CODEOWNERS‑Breite und Rotation. Weisen Sie Refactor‑Schichten anderen Approvern zu als Verhaltens‑Schichten.
• Verdeckte Kopplung: Verhaltensänderungen schleichen sich in Refactor‑PRs. Fix: Checklisten und CI‑Prüfungen, die Teständerungen in „keine Verhaltensänderung“‑PRs verbieten.
• CI‑Deadlocks: volle e2e‑Runs auf jeder Schicht blockieren die Queue. Fix: schwere Suiten nur an der Stack‑Spitze und bei der Merge‑Queue‑Integration ausführen.
• Flag‑Schulden: Sie landen fünf Stacks und vergessen die Flags zu bereinigen. Fix: eine SLA – veraltete Flags innerhalb von zwei Releases entfernen und auf tote Toggles alarmieren.

Implementierungsdetails, die Sie richtig machen sollten

• Auto‑Merge + Queue: verlangen Sie grüne Checks und lineare History, dann lässt die Queue Stacks der Reihenfolge nach landen. Menschen sollten keine Buttons babysitten.
• Geschützter „Landing‑Zone“‑Branch: manche Teams nutzen einen temporären Branch als Base für den Stack und rebasen den gesamten Stack kurz vor dem Queueing auf main. Das isoliert Churn während der aktiven Entwicklung.
• Vorlagen für PR‑Beschreibungen: stellen Sie einen Copy‑&‑Paste‑Block mit „Scope, Behavior, Tests, Flags, Risk, Revert Plan“ bereit. Das reduziert Bikeshedding und fehlenden Kontext.
• Visualisierung: nutzen Sie Labels wie „stack:1/4“ und verlinken Sie die Kette am Kopf jedes PRs. Reviewer sollten die Reihenfolge auf einen Blick sehen.
• Docs und Training: machen Sie eine 30‑minütige Live‑Demo eines echten Stacks. Geschriebene Docs ändern keine Gewohnheiten; zu sehen, wie ein 5‑PR‑Feature an einem Tag landet, schon.

Warum das gerade jetzt zählt

Zwei Trends kollidieren 2026: AI‑verstärktes Änderungsvolumen und strengere Zuverlässigkeits­erwartungen. Ihr Board will Features schneller. Ihre Kunden tolerieren keine Brüche. Stacked PRs bewegen beide Kurven in die richtige Richtung: kleinere, sicherere Deltas, die kontinuierlich integrieren, ohne Ihr Team zwischen Geschwindigkeit und Kontrolle wählen zu lassen.

Dass GitHub Stacked PRs shippt, entfernt die Plattform‑Ausrede. Es ist jetzt eine Prozessentscheidung – keine Tool‑Beschränkung. Wenn Ihre Organisation aus Gewohnheit auf „Big Bang“ defaultet, lassen Sie Durchsatz liegen und laden Freitag‑Überraschungen ein.

Stacked PRs ohne Drama einführen

Starten Sie mit einem Team, einem Feature, vier Wochen. Kappen Sie Stacks, flaggen Sie alles, tunen Sie die CI und messen Sie gnadenlos. Wenn sich Ihre Metriken nicht bewegen, justieren Sie die Grenzen, bis sie es tun. Wenn sie es tun, skalieren Sie horizontal – aber nur so schnell, wie Ihre Merge‑Queue und Ihre Reviewer mithalten können.

Wichtigste Erkenntnisse

• Stacked PRs verwandeln riskante Mega‑Diffs in sichere, reviewbare Schritte und sind jetzt nativ auf GitHub.
• Pilotieren Sie mit einem Stack‑Cap von 3–5 PRs, 100–300 LOC pro PR und 24/48‑Stunden‑Reviewer‑SLAs.
• Nutzen Sie Merge‑Queues, lineare History und stack‑fähige CI, um Ihre Pipelines nicht zu überlasten.
• Führen Sie schnelle Checks auf jeder Schicht aus; reservieren Sie schwere Suiten für die Stack‑Spitze und die Queue.
• Flags und Revert‑Drills machen jeden PR unabhängig sicher zu landen oder zurückzudrehen.
• Erwarten Sie 25–40% schnellere Time‑to‑Merge und weniger konfliktgetriebene Feuerübungen; ohne Build‑Invalidierung können CI‑Kosten steigen.
• Vermeiden Sie Fehlermuster: endlose Stacks, Review‑Stampeden, versteckte Verhaltensänderungen und Flag‑Schulden.
• Messen Sie DORA‑Metriken und Konflikt‑Nacharbeit; wenn sie sich nicht verbessern, fixen Sie Scope‑Kontrolle oder CI, bevor Sie skalieren.

Author: Diogo Hudson Dias