GitHub Stacked Pull Requests: So arbeiten Teams und KI-Agenten schneller

Kurz gesagt: GitHub Stacked Pull Requests zerlegen große Änderungen in eine geordnete Kette kleiner Pull Requests. Das beschleunigt Reviews, reduziert unübersichtliche Mega-PRs und passt besonders gut zu Teams, in denen Entwickler und KI-Agenten gleichzeitig Code erzeugen. Für den Einstieg solltest du ein überschaubares Feature als Stack abbilden und klare Verantwortlichkeiten pro Ebene festlegen.

Was ist passiert?

GitHub hat Stacked Pull Requests am 30. Juli 2026 als öffentliche Vorschau vorgestellt. Die Funktion verbindet mehrere voneinander abhängige Pull Requests zu einem sichtbaren Stack. Jede Ebene lässt sich separat prüfen und mit bestehenden Branch-Regeln sowie automatisierten Tests absichern. GitHub stellt dafür außerdem die CLI-Erweiterung gh-stack und einen Skill für Coding-Agenten bereit. Die Funktion wird schrittweise ausgerollt und kann sich während der Vorschau noch verändern.

Was sind GitHub Stacked Pull Requests?

Stacked Pull Requests, auf Deutsch etwa gestapelte Pull Requests, sind mehrere kleine Pull Requests, die bewusst aufeinander aufbauen. Der unterste Pull Request zielt normalerweise auf main. Jeder weitere Pull Request verwendet den Branch der darunterliegenden Ebene als Basis.

Statt eine komplette Funktion in einem einzigen Pull Request mit hunderten Änderungen einzureichen, wird die Arbeit nach Abhängigkeiten getrennt:

• PR 1: Datenmodell und grundlegende Typen, Zielbranch: main
• PR 2: API und Geschäftslogik, Zielbranch: Branch aus PR 1
• PR 3: Benutzeroberfläche, Zielbranch: Branch aus PR 2
• PR 4: automatisierte Tests, Zielbranch: Branch aus PR 3

Reviewer sehen in jedem Pull Request nur die Änderungen dieser Ebene. Trotzdem bleibt in GitHub sichtbar, an welcher Stelle der Pull Request innerhalb des gesamten Stacks steht.

Wie funktionieren Stacked Pull Requests?

Das Prinzip ist einfach: Abhängige Änderungen werden als nachvollziehbare Kette modelliert. Eine höhere Ebene darf Code aus den darunterliegenden Ebenen verwenden, weil ihr Branch bereits darauf basiert.

Wird eine untere Ebene geändert, können die darüberliegenden Branches kaskadierend neu aufgesetzt werden. Beim Zusammenführen gilt die Reihenfolge von unten nach oben. Wird der oberste bereite Pull Request zusammengeführt, können alle offenen Ebenen darunter in einem Vorgang landen. Wird nur ein mittlerer Teil zusammengeführt, bleiben die höheren Pull Requests geöffnet und werden automatisch auf die neue Basis ausgerichtet.

Branch-Schutz, erforderliche Freigaben, CODEOWNER-Regeln und CI-Prüfungen gelten für jede Ebene. So muss jede einzelne Änderung denselben Qualitätsstandard erfüllen.

So nutzt du GitHub Stacked Pull Requests

Am schnellsten startest du mit der offiziellen GitHub-CLI-Erweiterung. Voraussetzung sind GitHub CLI ab Version 2.90.0, Git ab Version 2.20 und ein Repository, in das du Branches pushen darfst.

1. Erweiterung installieren: gh extension install github/gh-stack

2. Bei GitHub anmelden: gh auth login

3. Ersten Stack beginnen: gh stack init feature-auth

Danach entwickelst und commitest du die erste abgeschlossene Änderung wie gewohnt.

4. Nächste Ebene ergänzen: gh stack add feature-api

5. Stack veröffentlichen: gh stack submit

6. Status anzeigen: gh stack view

Musst du eine untere Ebene korrigieren, wechselst du mit gh stack down oder gh stack checkout BRANCH-NAME zum passenden Branch. Anschließend verteilt gh stack rebase --upstack die Änderung auf die darüberliegenden Ebenen. Nach Merges aktualisiert gh stack sync --prune den lokalen Stand.

Alternativ kannst du einen Stack direkt auf github.com erstellen. Dabei zielt jeder neue Pull Request auf den Branch der vorherigen Ebene. GitHub bietet anschließend an, die zusammenhängenden Pull Requests als Stack zu verknüpfen.

Praxisbeispiel: Ein neues Kundenportal

Ein gutes Beispiel ist die Entwicklung eines Kundenportals mit Anmeldung, API und Dashboard. Ohne Stack könnte daraus ein großer Pull Request entstehen, in dem Datenbankänderungen, Backend, Frontend und Tests gleichzeitig geprüft werden müssen.

• Ebene 1 – Authentifizierung: Ein Entwickler erstellt Benutzerrollen, Datenbankmigrationen und die Anmeldung.
• Ebene 2 – API: Ein KI-Agent ergänzt geschützte Endpunkte für Kunden- und Vertragsdaten.
• Ebene 3 – Dashboard: Eine Mitarbeiterin entwickelt mit KI-Unterstützung die Oberfläche und nutzt die API aus Ebene 2.
• Ebene 4 – Qualitätssicherung: Ein Test-Agent erstellt automatisierte Tests für Anmeldung, Berechtigungen und Benutzerabläufe.

Die API muss nicht warten, bis die Authentifizierung in main gelandet ist. Das Dashboard kann bereits auf der API-Ebene aufbauen. Gleichzeitig prüfen verschiedene Reviewer die einzelnen Pull Requests unabhängig voneinander, während das gesamte Feature als zusammenhängender Stack erkennbar bleibt.

Warum Stacked Pull Requests bei mehreren KI-Agenten besonders wertvoll sind

Der größte Vorteil liegt nicht darin, möglichst viel Code gleichzeitig zu erzeugen, sondern die wachsende Menge an Änderungen kontrollierbar zu halten. KI-Agenten können schneller Code produzieren, als Menschen einen riesigen Pull Request sinnvoll prüfen können. Stacks setzen dieser Geschwindigkeit eine klare Struktur entgegen.

• Kleinere Prüfbereiche: Jeder Agent oder Mitarbeitende liefert eine abgegrenzte Änderung statt eines schwer verständlichen Gesamtpakets.
• Explizite Abhängigkeiten: GitHub zeigt, welche Änderung auf welcher Grundlage aufbaut.
• Parallele Reviews: Während eine Person die Datenmodelle prüft, kann eine andere bereits API oder Oberfläche bewerten.
• Früheres Feedback: Architekturfehler in unteren Ebenen werden sichtbar, bevor sie sich durch das gesamte Feature ziehen.
• Bessere Nachvollziehbarkeit: Es bleibt erkennbar, welcher Mensch oder Agent welche Aufgabe umgesetzt hat.
• Kontrollierte Freigabe: Tests, Reviews und Branch-Schutz bleiben verbindliche Qualitätsgrenzen, auch wenn Agenten Code erzeugen.

Mehrere Agenten sollten allerdings nicht ungeplant dieselben Dateien verändern. Für wirklich parallele Arbeit eignen sich getrennte Stacks oder klar getrennte Verantwortungsbereiche. Innerhalb eines Stacks können höhere Ebenen schon vor dem Merge beginnen, müssen aber konsequent auf dem aktuellen Stand der unteren Ebenen aufbauen.

Wo liegen die Grenzen?

Stacked Pull Requests lösen das Review-Problem, ersetzen aber keine saubere Aufgabenplanung. Ein schlecht geschnittener Stack kann genauso schwer verständlich werden wie ein großer Pull Request.

• Zu viele Ebenen: Sehr lange Stacks erhöhen den Abstimmungsaufwand und können viele CI-Läufe auslösen.
• Falsche Reihenfolge: Typen, Schnittstellen und Datenmodelle gehören nach unten; abhängige Oberflächen und Tests nach oben.
• Unklare Zuständigkeit: Jede Ebene braucht eine konkrete Aufgabe und eine verantwortliche Person oder einen Agenten.
• Zu große Einzel-PRs: Ein Stack hilft wenig, wenn jede Ebene weiterhin tausende unübersichtliche Zeilen enthält.

Alle Branches eines GitHub-Stacks müssen im selben Repository liegen. Cross-Fork-Stacks und GitHub Desktop werden derzeit nicht unterstützt. Wegen des Vorschau-Status empfiehlt sich zunächst ein kontrollierter Testlauf.

Was du jetzt tun solltest:

Der sinnvollste Einstieg ist ein echtes, aber überschaubares Feature mit drei bis vier logisch abhängigen Ebenen. So erkennt dein Team schnell, ob Branch-Schnitt, Review-Regeln und CI zum eigenen Entwicklungsprozess passen.

• Sofort: Prüfe GitHub-CLI und Git-Version und installiere gh-stack in einem Test-Repository.
• Kurzfristig: Definiere Regeln für PR-Größe, Benennung, Verantwortlichkeit und technische Abhängigkeiten.
• Mittelfristig: Binde KI-Agenten so ein, dass jede Aufgabe einen klaren Scope, einen eigenen Pull Request und menschliche Abnahmekriterien besitzt.

Für Softwareteams in Duisburg und im Ruhrgebiet ist das besonders interessant, wenn individuelle Web-Apps, Plattformen oder interne Tools mit KI-Unterstützung schneller entwickelt werden sollen, ohne Review und Qualitätssicherung zum neuen Engpass werden zu lassen.

Häufige Fragen

Sind Stacked Pull Requests nur für große Entwicklerteams geeignet?

Nein. Bereits zwei Entwickler profitieren, wenn eine Funktion aus mehreren abhängigen Teilen besteht. Besonders nützlich wird der Workflow, sobald mehrere Personen oder KI-Agenten Änderungen erzeugen, während Reviews und Tests nachvollziehbar bleiben müssen.

Können mehrere KI-Agenten gleichzeitig an einem Stack arbeiten?

Ja, aber nur koordiniert. Agenten können unterschiedliche Ebenen oder klar getrennte Aufgaben bearbeiten. Gemeinsame Grundlagen gehören in die unteren Ebenen. Für unabhängige Features sind getrennte Stacks häufig die bessere Wahl.

Muss der gesamte Stack auf einmal zusammengeführt werden?

Nein. GitHub kann den gesamten Stack oder einen zusammenhängenden unteren Teil zusammenführen. Die Reihenfolge bleibt von unten nach oben erhalten. Höhere Ebenen können offen bleiben und werden automatisch auf die neue Basis ausgerichtet.

Du möchtest KI-gestützte Softwareentwicklung nutzen, ohne Kontrolle, Wartbarkeit und Codequalität zu verlieren? Kontaktiere uns bei Zeasy Software — von der Idee zum Tool, für Unternehmen in Duisburg und dem Ruhrgebiet.