GitHub Stacked PRs: kleiner Diff, andere Deployment-Grenze
Drei kleine PRs machen eine große Änderung leichter lesbar. Hängt ein oberer PR vom unteren ab, ist er dadurch aber nicht unabhängig auslieferbar.
Die Veröffentlichung vom 6. Oktober
GitHub erklärte Stacked Pull Requests am 6. Oktober 2026 für allgemein verfügbar. Kleine PRs lassen sich einzeln prüfen und gemeinsam mergen; die Funktion ist auf allen github.com-Plänen verfügbar.
Ein Stack geht laut Ankündigung als eine Merge-Gruppe durch die Merge Queue. Bei der Merge-Commit-Methode entsteht dagegen ein Commit pro PR. Testgruppe und Commit-Einheit sind also verschieden.
Review-Grenzen aufschreiben
Beispiel: A ergänzt eine Funktion, B verwendet sie in einer API, C baut die Oberfläche. Beschreibe Abhängigkeiten und Vergleichsbasis je PR. Das ist ein Workflow-Vorschlag, keine automatische Produktgarantie.
Wer nur B liest, könnte eine fehlende Berechtigungsprüfung in A übersehen. Prüft den einzelnen Diff und die Kombination A+B+C getrennt und benennt die Verantwortung für die Integration.
Freigaben nach einem Rebase lesen
GitHub erhält Freigaben beim Rebase eines ansonsten unveränderten Stacks nach Änderungen der Basis, auch bei Regeln zum Verwerfen alter Freigaben. Freigabe und aktuelle Integrationsevidenz bleiben getrennte Signale.
Notiert Commit-SHAs vor und nach dem Rebase sowie die getestete Merge-Gruppe. Prüft, ob Tests erneut liefen und welche Kombination die Logs belegen; ein grünes Symbol allein reicht nicht.
Merge und Deployment trennen
Müssen Funktion und API gemeinsam ausgeliefert werden, gehört das in den Deployment-Plan. Ein Commit pro PR garantiert keinen sicheren Einzel-Rollback, wenn andere Aufrufer verbleiben.
Unabhängige Fehlerkorrekturen brauchen keinen Stack. Eine unnötige Kopplung kann alle PRs auf eine verzögerte Prüfung warten lassen. Das ist eine betriebliche Abwägung.
GA und tatsächliche Verfügbarkeit
Auto-Merge wird laut GitHub in den kommenden Wochen ausgerollt. Prüft sichtbare Funktionen im Repository, statt heute dieselben Schaltflächen für jedes Konto vorauszusetzen.
Die Ankündigung verweist auf Verbesserungen aus Preview-Rückmeldungen. Interesse ist keine Produktivitätsgarantie; messt eigene Review-Wartezeiten und Integrationsfehler.
Mit einem kleinen Stack testen
Beginnt mit zwei klar abhängigen PRs, etwa Funktion und Aufrufer. Dokumentiert Basis, Abhängigkeit und Testbefehle und vereinbart Integrationsverantwortung sowie Rollback-Umfang.
Vergleicht kürzere Reviews mit möglichen Integrationsfehlern. Falls die Pflege mehr kostet, sind gewöhnliche PRs weiterhin sinnvoll. Entscheidend ist weniger Verwirrung beim Prüfen und Ausliefern.
Offizielle Quellen
Ankündigung vom 6. Oktober; geprüft am 8. Oktober 2026. Repository-Regeln und verfügbare Funktionen vor der Einführung prüfen.