Githubs größte Veröffentlichung seit Jahren. Stacked PRs.

Deutschالعربية English Español Français हिन्दी Bahasa Indonesia 日本語 한국어 Português Русский 中文

Computing/SoftwareInternet Technology

Transcript

00:00:00GitHub hat gerade sein größtes Update seit Jahren veröffentlicht: Stacked PRs, eine völlig neue Art,

00:00:05massive Pull Requests in überschaubarere Teile zu zerlegen. In diesem Video schauen wir uns genau an, was sie sind

00:00:10und warum man sie nutzen sollte. Stacked PRs sind ein mächtiges, aber recht einfaches Konzept. Man bricht große Codeänderungen

00:00:21in eine Kette kleinerer, voneinander abhängiger Pull Requests auf. Diese lassen sich unabhängig voneinander prüfen und mergen.

00:00:26Für einen Stack benötigt man zwei oder mehr Pull Requests im selben Repository, wobei der erste

00:00:31bzw. unterste Pull Request auf den Hauptzweig abzielt – meist den Standardbranch des Repositories wie main.

00:00:37Jeder nachfolgende Pull Request zielt dann auf den vorherigen ab. Das bildet eine Abhängigkeitskette,

00:00:42bei der jeder Branch auf dem darunterliegenden aufbaut. Grundlegende Änderungen wie gemeinsame Typen oder Datenbankschemata

00:00:48landen in den unteren Branches, während Code, der davon abhängt – wie API-Routen und UI-Komponenten –,

00:00:53in die höheren Branches kommt. Und du denkst dir vielleicht: „Das konnte ich doch schon immer machen, oder?“

00:00:58Ich konnte einen PR nach main öffnen, dann einen zweiten PR auf diesen PR erstellen und PRs beliebig aneinanderhängen.

00:01:04Das stimmt absolut, denn im reinen Kontext von Git gibt es so etwas wie Stacked PRs eigentlich nicht

00:01:09und man würde PRs nur per Daisy-Chaining verknüpfen. Erst direkt innerhalb von GitHub bedeuten Stacked PRs

00:01:16tatsächlich etwas. Sie bringen jedoch massive Vorteile mit sich. Und wenn du bezüglich Tech und KI

00:01:22auf dem Laufenden bleiben willst, abonniere Better Stack. Um Stacked PRs optimal zu nutzen, installiert man am besten

00:01:27die GitHub CLI. Damit kann man gh stack init ausführen und dann seinen neuen Stack deklarieren.

00:01:33Gehen wir also in unseren Texteditor und schauen uns ein Beispiel für das Stapeln mehrerer PRs an.

00:01:38Als Erstes führen wir gh stack init setup database aus. In diesem Fall

00:01:44wird der PR bzw. der Branch setup database heißen. Das wird der Basis-PR sein, der nun

00:01:50auf main verweist. Dann können wir unsere Änderungen vornehmen. Für diese Demo füge ich Änderungen

00:01:54einfach in die Readme-Datei ein. Ich trage also ein, dass ich die Datenbank implementiert habe, und dann macht man git add

00:01:59und git commit. Alles hier ist also Standard-Git. Wenn du dann zu deinem nächsten Satz

00:02:04von Änderungen wechseln willst, kannst du gh stack add und danach deinen nächsten Branch eingeben. Danach kann ich weitere Änderungen machen,

00:02:10wie das Erstellen der API-Endpunkte. Vielleicht möchte ich hier noch ein paar Punkte hinzufügen. Also committe ich diese Änderung.

00:02:16Dann können wir auch eine zweite Änderung hinzufügen und diese ebenfalls committen. Wie zu erwarten,

00:02:20kann man mehrere Commits pro Branch erstellen. Schließlich führen wir gh stack add setup frontend aus

00:02:25und nehmen hier noch eine letzte Änderung vor. Wieder machen wir git add und git commit. Wenn wir mit

00:02:31allen unseren Änderungen zufrieden sind und alle diese Branches gleichzeitig zu GitHub hochladen wollen,

00:02:36können wir einfach einen einzigen Befehl ausführen: gh stack submit. Das öffnet eine Mini-CLI-Benutzeroberfläche,

00:02:42in der wir jeden einzelnen PR im Stack durchgehen und auf Wunsch Titel und Beschreibung hinzufügen können. Oder wir klicken

00:02:48bei jedem einfach auf Weiter und reichen so drei PRs auf einmal ein. Man sieht also, dass alle drei PRs –

00:02:55setup database, API und frontend – mit einem einzigen Befehl als Stack zu GitHub gepusht wurden.

00:03:02Das Ganze lässt sich übrigens auch komplett ohne die GitHub CLI erledigen. Man folgt einfach der althergebrachten Methode,

00:03:07PRs manuell von main zu PR1 und PR2 zu verknüpfen. GitHub erkennt diese dann ebenfalls als Stack,

00:03:14sobald man sie hochlädt. Die CLI macht die Verwaltung lediglich wesentlich einfacher. Denke daran, dass sich an Git selbst

00:03:20nichts geändert hat. Wenn du einen völlig anderen Branch auschecken möchtest, der nicht Teil des Stacks ist,

00:03:24an dem du arbeitest, kannst du das tun und später einfach zu dem Branch im Stack zurückkehren.

00:03:29Wenn wir nun zu GitHub selbst wechseln, sehen wir unsere drei PRs, die hier als

00:03:34Pull Requests erstellt wurden. Außerdem gibt es dort dieses kleine Stack-Symbol, das uns anzeigt, dass diese

00:03:39PRs zu einem Stack gehören. Wenn wir den obersten PR öffnen (also den am Ende des Stacks), sehen wir

00:03:45weiter unten die Schaltfläche „Merge Stack“ und erkennen auch diese Benutzeroberfläche. So haben wir jeden einzelnen

00:03:49PR des Stacks im Blick. Wir könnten das Ganze Schritt für Schritt durchgehen und einzeln freigeben. Wenn wir jedoch

00:03:54mit allem zufrieden sind, reicht ein Klick auf „Merge Stack“, und jeder einzelne dieser PRs wird

00:03:59gleichzeitig nach main gemergt. Dir wird außerdem auffallen, dass Verweise auf Stacks mittlerweile

00:04:03in ganz GitHub integriert sind. Man sieht sie auf der Pull-Request-Seite und auf der

00:04:09Übersichtsseite der Pull Requests. Sie tauchen auch bei Dingen wie GitHub Workflows und im Grunde in der gesamten

00:04:14Anwendung auf. Wer also an massiven PRs arbeitet und eine einfache Möglichkeit sucht, diese

00:04:18in separate Teile aufzuteilen, muss nicht länger darauf warten, dass einzelne PRs nach main gemergt werden,

00:04:23und das ganze Rebase- und Merge-Chaos selbst erledigen. Man kann einfach einen langen Stack erstellen, und GitHub

00:04:28ist nun bestens gerüstet, um das alles direkt in der Benutzeroberfläche zu verwalten. Die CLI bietet dabei einen wirklich tollen Weg,

00:04:33um das Ganze vollautomatisch zu steuern. Die Resonanz darauf online war

00:04:38überwältigend positiv. Vor allem in Kombination mit KI halte ich das für ein extrem mächtiges Feature,

00:04:43etwa wenn man agentische Schleifen einsetzt und den Agenten stundenlang arbeiten lässt. Dieser kann nun

00:04:48Stacked PRs erstellen und die gesamte Arbeit verknüpfen, anstatt entweder einen gigantischen PR oder Unmengen

00:04:54völlig isolierter PRs zu erzeugen. Aber ich hoffe, das Video war hilfreich für euch. Lasst mich in den Kommentaren wissen,

00:04:58was ihr von Stacked PRs haltet, und abonniert Better Stack, um bei den neuesten Tech-

00:05:02und KI-News auf dem Laufenden zu bleiben. Danke fürs Zuschauen und bis zum nächsten Mal!

Key Takeaway

GitHubs neue Stacked-PRs-Funktion und die GitHub CLI erlauben das gleichzeitige Erstellen und Zusammenführen ganzer Ketten abhängiger Pull Requests mit dem Befehl gh stack submit.

Highlights

Stacked PRs teilen massive Codeänderungen in eine Kette kleinerer, voneinander abhängiger Pull Requests auf.
Die GitHub CLI ermöglicht die Erstellung von Stacks durch Befehle wie gh stack init, gh stack add und gh stack submit.
Ein einzelner Klick auf Merge Stack führt alle Pull Requests des Stacks gleichzeitig in den Hauptzweig main zusammen.
GitHub zeigt Stack-Symbole und Verweise auf Pull-Request-Seiten, Workflows und Übersichten an.
Die Kombination aus Stacked PRs und KI-Agenten automatisiert die Erstellung verketteter Pull Requests.

Timeline

Konzept und Struktur von Stacked PRs

Stacked PRs unterteilen große Codeänderungen in kleinere, aufeinander aufbauende Pull Requests.
Der unterste Pull Request zielt auf den Hauptzweig main ab, während jeder weitere PR auf dem vorherigen basiert.
Grundlegende Änderungen wie Datenbankschemata liegen in den unteren Branches, während API-Routen und UI-Komponenten in den höheren Branches folgen.

Große Codeänderungen werden in eine Kette kleinerer, voneinander abhängiger Pull Requests aufgeteilt. Diese lassen sich unabhängig prüfen. Im reinen Git-Kontext existieren Stacked PRs traditionell nur durch Daisy-Chaining, erhalten jedoch durch die direkte Integration in GitHub eine völlig neue Bedeutung.

Verwendung der GitHub CLI für Stacks

Der Befehl gh stack init setup database startet einen neuen Stack mit einem Basis-PR auf main.
Mit gh stack add lassen sich weitere Branches wie API-Endpunkte und Frontend-Komponenten anfügen.
Der Befehl gh stack submit öffnet eine Mini-CLI-Benutzeroberfläche und lädt alle PRs im Stack gleichzeitig hoch.

Die GitHub CLI vereinfacht die Verwaltung von Stacks erheblich. Nach der Initialisierung mit gh stack init und dem Hinzufügen weiterer Änderungen über gh stack add lassen sich sämtliche Commits mit einem einzigen Befehl als Stack zu GitHub übertragen.

Verwaltung und Zusammenführung auf GitHub

Alternative Pull-Request-Verknüpfungen von main zu PR1 und PR2 werden von GitHub ebenfalls als Stack erkannt.
Ein Klick auf die Schaltfläche Merge Stack am Ende des Stacks führt alle verknüpften Pull Requests gleichzeitig nach main zusammen.
Die Integration von Stacks erstreckt sich über Pull-Request-Seiten, Workflows und Übersichten in der gesamten GitHub-Anwendung.

GitHub zeigt Stack-Symbole direkt in der Benutzeroberfläche an. Entwickler müssen nicht länger auf das Mergen einzelner PRs warten, um Rebase- und Merge-Chaos manuell zu lösen. Insbesondere in Kombination mit KI-Agenten entsteht ein mächtiges Werkzeug für umfangreiche Entwicklungsarbeiten.

Community Posts

Write about this video