GitHub Stacked PRs

 (github.github.com/gh-stack)
9 Punkte von GN⁺ 16 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Neue Funktion von GitHub, mit der sich große Codeänderungen in kleine, prüfbare PR-Einheiten aufteilen und nacheinander verwalten lassen
  • Jeder PR wird unabhängig geprüft, und der gesamte Stack kann mit einem Klick zusammengeführt werden
  • Über die GitHub-UI und die gh stack-CLI werden Erstellen, Navigieren, Rebasen und Mergen von Stacks unterstützt; eine Stack-Map visualisiert die Hierarchie
  • Durch die Integration von KI-Coding-Agenten lassen sich große Diffs automatisch in Stack-Einheiten aufteilen oder stackbasierte Entwicklung durchführen
  • Ziel ist es, die Komplexität und das Konfliktrisiko großer PRs zu verringern und Review-Effizienz sowie Entwicklungsgeschwindigkeit im Team zu erhöhen

Hauptfunktionen

  • Verwaltung von Stacked PRs

    • Mehrere PRs werden in Form eines geordneten Stacks organisiert, wobei jeder PR auf dem Branch des direkt darunterliegenden PR basiert
    • Dadurch entsteht eine Kettenstruktur, die am Ende den Main-Branch erreicht
    • GitHub erkennt den gesamten Stack und zeigt in der UI eine Stack-Map an, sodass Reviewer jede Ebene leicht durchgehen können
    • Branch-Schutzregeln gelten für den endgültigen Ziel-Branch, und CI-Tests werden für alle PRs im Stack ausgeführt

  • Vereinfachtes Stack-Management

    • In der GitHub-UI kann man zwischen PRs im Stack wechseln, den Status jeder Ebene prüfen und ein kaskadierendes Rebase für den gesamten Stack ausführen
    • Der gesamte Stack oder auch nur ein Teil davon kann mit einem Klick gemergt werden
    • Nach dem Merge werden verbleibende PRs automatisch rebased, sodass der unterste noch nicht gemergte PR auf den Standard-Branch ausgerichtet wird

  • Starke CLI-Unterstützung

    • Mit der gh stack-CLI lassen sich Stacks erstellen, rebasen, Branches pushen, PRs erzeugen und zwischen Ebenen wechseln – direkt im Terminal
    • Beispiele für CLI-Befehle
      • gh extension install github/gh-stack : Erweiterung installieren
      • gh stack alias : Kurzbefehle einrichten
      • gs init <branch> : Ersten Branch erstellen
      • gs add <branch> : Neue Ebene hinzufügen
      • gs push : Alle Branches pushen
      • gs submit : PRs für den gesamten Stack erstellen

  • Integration von KI-Agenten

    • Mit dem Befehl npx skills add github/gh-stack kann ein KI-Coding-Agent dafür eingerichtet werden, Stack-Aufgaben auszuführen
    • Große Diffs lassen sich automatisch in Stack-Einheiten aufteilen oder von Anfang an stackbasiert entwickeln

Warum Stacked PRs nötig sind

  • Große PRs führen zu schwierigerem Review, verzögertem Merge und höherem Konfliktrisiko
    • Reviewer verlieren den Kontext, die Qualität des Feedbacks sinkt und das gesamte Team wird langsamer
  • Stacked PRs lösen das, indem sie Änderungen in kleine, fokussierte PR-Ketten aufteilen
    • Jeder PR kann unabhängig geprüft werden, während sich die Gesamtänderung schrittweise aufbaut

Erste Schritte

Verwandte Beiträge

1 Kommentare

 
GN⁺ 16 일 전
Hacker-News-Kommentare

  • Was ich brauche, ist nicht „stacked PR“, sondern eine UI zur Verwaltung einzelner Commits

    • Ich möchte nur bestimmte Commits separat mergen oder einen bestimmten Commit als fertig geprüft markieren
    • Ich möchte interactive rebase/squash/edit auf Commit-Ebene machen, aber in der GitHub-UI ist das nicht möglich
    • Es braucht eine Funktion, um Commit-Nachrichten oder bestimmte Commits zu kommentieren, sowie diff of diff, um Änderungen zwischen Force-Pushes zu visualisieren
      Git hat bereits das Commit-Konzept — ich verstehe nicht, warum man darüber noch die Abstraktion „stacked PR“ legen muss
    • Das ist das von Phabricator bekannte stacked-diff-Workflow-Konzept, übertragen auf GitHub
      Damit kann man leichter neue Arbeit auf noch nicht gemergten Änderungen aufbauen, und Reviewer können große Änderungen in kleinen Einheiten unabhängig reviewen
      Besonders nützlich war das in großen Monorepos oder Unternehmensumgebungen
    • Aber ich habe das Gefühl, dass ständiges Umschreiben der Git-Historie riskant ist
      Wiederholt squashen, rebasen und force-pushen fühlt sich an, als würde man sich selbst ins Bein schießen
      Mit git merge --no-ff, git log --first-parent, git bisect --first-parent kann man im Grunde denselben Effekt erreichen
    • Das Beste war die SuperSmartLog (SSL), die wir bei Meta verwendet haben
      Die Doku zu interactive smartlog ist öffentlich, und es gibt auch eine VSCode-Erweiterung
      Schade, dass es sich überraschenderweise nicht stärker verbreitet hat
    • Mein bevorzugter Workflow ist, PRs/MRs als „atomare Änderungen“ zu betrachten
      Commits dienen dabei als Entwicklungsverlauf, um diesen PR zu vervollständigen
      1. Wenn ein PR zu groß ist, teile ich ihn in Commits auf
      2. Ich halte den Entwicklungsprozess des PR in Commits fest, einschließlich der Begründung („foo zu bar geändert“ usw.)
    • Was du beschreibst, ist im Grunde Gerrit

  • Nach Phabricator und Mercurial fühlt sich die Rückkehr zu GitHub an wie eine Reise zurück in die Steinzeit
    Deshalb freue ich mich über jujutsu oder diese neue Funktion, die den stacked-diff-Ablauf wiederherstellen
    Nicht nur in Monorepos, sondern auch bei langfristiger Feature-Entwicklung hilft das, Reviews klein und schnell zu halten

    • Es ist wirklich gut, dass Git die DVCS-Kriege gewonnen hat
      Mercurial behauptete immer, „schneller als Git“ zu sein, war in der Praxis aber oft langsamer oder kaputt
      Git ist hässlich, aber schnell und zuverlässig
    • Ich mag GitHub-Reviews immer noch nicht und nutze deshalb Gerrit
      Beim Review großer Änderungen, etwa bei Updates von Vendor-Abhängigkeiten, ist die Dateireview-Erfahrung auf GitHub eher schwach
    • Ich vermisse die Review-UI von Phabricator sehr

  • Endlich ist es da!
    Das GitHub-Modell „PR = Branch“ war für mich nie wirklich nachvollziehbar
    Stacked Commits im Stil von Phabricator/Gerrit passen viel besser zu meiner Denkweise
    Jetzt muss ich wohl die CLI installieren

    • Schade, dass es von der GH CLI abhängt, aber hoffentlich gibt es zum GA-Zeitpunkt auch UI-Support
    • In meinem mentalen Modell verstehe ich den Unterschied zwischen Branches und stacked PRs nicht wirklich
      Ein Branch ist letztlich nur eine Markierung auf Commits, und mehrere Zwischenpunkte zu behalten ergibt nur dann Sinn, wenn frühere Teile unabhängig gemergt werden können

  • Ich frage mich, ob damit das aktuelle Squash-&-Merge-UX-Problem gelöst ist
    Ich staple heute manuell nach dem Muster main <- PR A <- PR B <- PR C,
    und wenn PR A zuerst gemergt wird, wird PR B zur Konflikthölle
    Die GitHub-UI ändert dann automatisch den Ziel-Branch auf main, wodurch seltsame Konflikte entstehen
    Ich brauche einfach ein Tool, das „einfach funktioniert“

    • Die Konflikte entstehen wahrscheinlich, weil PR A per Squash-Merge gemergt wurde
      Hoffentlich löst gh stack sync das per rebase --onto
    • Tatsächlich wird das in CLI und Server mit git rebase --onto behandelt
      Beispiel: PR1(main<-A,B), PR2(main<-A,B,C,D), PR3(main<-A,B,C,D,E,F)
      Wenn PR1 und PR2 per Squash gemergt werden, ist main danach S1(A+B), S2(C+D)
      Danach kann man mit git rebase --onto S2 D branch3 ohne Konflikte aufräumen
    • In meinem Workflow sollte, wenn A gemergt ist, B eigentlich ebenfalls schon gemergt sein
      Das lässt sich mit git rebase --update-refs --onto origin/main A C lösen
      Die GH CLI automatisiert diesen Prozess
    • Das ist eher eine logische Grenze von Git als ein Bug
    • Ich stimme zu, dass das nervig und unintuitiv ist
      Aber am Ende bleibt als Lösung nur, die Commits manuell per Rebase aufzuräumen

  • Wenn man alleine entwickelt, braucht man stacked PRs kaum, aber die Gewohnheit, in kleine Einheiten aufzuteilen, bleibt wichtig
    AI-Tools wie Claude Code erzeugen oft auf einmal große Diffs,
    daher wäre es interessant, wenn ein Agent seine Arbeit selbst in logische Einheiten zerlegen könnte

    • PRs können ohnehin schon aus mehreren Commits bestehen, also gilt wohl: Wenn ein Agent darin nicht gut navigieren kann, wird es bei stacked PRs auch nicht besser
    • Ich nutze Claude zusammen mit jj, damit der Arbeitsstapel über dem Trunk review-freundlich umstrukturiert wird
    • Wenn man kleine Branches voneinander abhängig macht, entsteht Synchronisationshölle, sobald ein früherer Branch aktualisiert wird
    • Einen entsprechenden Leitfaden zur Agenten-Integration gibt es auf der Webseite

  • git-spice ist ebenfalls einen Blick wert
    Es ist mit GitLab usw. kompatibel, und ich nutze inzwischen komplett git-spice statt der üblichen Git-Befehle

  • Es ist cool, dass GitHub endlich eine Stack-Funktion in die UI eingebaut hat
    Ähnlich wie glab stack bei GitLab
    Der Merge-Prozess wirkt aber etwas ungelenk — wenn man unten im Stack etwas merged, werden die restlichen Teile neu gerebased und CI läuft erneut
    Wenn ich von drei Patches nur die unteren zwei mergen will, muss ich jeweils wieder auf Tests warten

    • Im aktuellen Design kann man, wenn die CI der unteren zwei PRs erfolgreich ist, beide auf einmal mergen
      Danach wird der obere Teil des Stacks gerebased und CI kann erneut anlaufen
      Dieser Punkt soll in der Dokumentation noch klarer ergänzt werden

  • Ich verstehe den Bedarf an stacked PRs nicht so recht
    In Git kann man Patch-Sets grundsätzlich einzeln reviewen und anwenden
    Das PR-Modell macht daraus eher einen einzigen Block
    Stacked PRs wirken wie noch eine weitere Abstraktion, um dieses Problem zu umgehen

    • In einem Team, in dem ich gearbeitet habe, galten PRs selbst als „kleinste anwendbare Einheit“
      Interne Commits sind nur Entwicklungshistorie, und beim Mergen wird alles per squash zu einem Commit zusammengeführt
      So kann man während der Entwicklung frei Commits stapeln und am Ende trotzdem nur eine saubere Änderung hinterlassen
    • In Phabricator war das Verhältnis von Commit zu Diff 1:1, was viel natürlicher wirkte
      Die GitHub-Umsetzung fühlt sich ein bisschen wie angeklebte Funktionalität an
    • Ein PR ist ursprünglich eine atomare Änderungseinheit, und stacked PRs erlauben es, neue PRs darauf aufzubauen
      Es ist also eine Struktur, in der Arbeit schrittweise in reviewbaren Einheiten gestapelt wird

  • Es gibt bereits das Startup Graphite, das sich auf stacked PRs konzentriert
    Ich nutze Graphite schon länger, und es freut mich, dass GitHub jetzt etwas Ähnliches umgesetzt hat

    • Auch bei uns im Unternehmen nutzen wir Graphite und sind zufrieden damit

  • Ich mag stacked PRs, aber die GitHub-Implementierung fühlt sich diesmal merkwürdig an
    Es würde doch reichen, wenn jeder Branch einfach auf seinen Parent zeigen würde
    Wichtiger als die CLI wäre für mich UI-Unterstützung

    • Aber Rebase wird schmerzhaft, nachdem der Parent-Branch gemergt wurde
      Es wäre gut, wenn die CLI diesen Prozess automatisieren würde
    • Die CLI ist optional, und stacked PRs lassen sich auch in der UI erstellen
      Der Grund für die Branch-Kette ist, dass der Diff nur die Änderungen dieses Branches zeigen soll
    • Eigentlich war das schon immer mit Git selbst möglich
      Es fehlte nur an UI und Visualisierung
    • Als Nächstes hoffe ich auf Verbesserungen an der UI