Die Erweiterung gh stack für GitHub CLI erstellt und verwaltet Stapel von Pull Requests aus Ihrem lokalen Repository. Eine Einführung in Stacks finden Sie unter Gestapelte Pull Requests.
Installation
gh extension install github/gh-stack
Die Erweiterung erfordert GitHub CLI (gh) Version 2.0 oder höher und Git 2.36 oder höher.
Hinweis
Die gh stack Erweiterung verwendet Ihre GitHub CLI Authentifizierung. Wenn Sie sich noch nicht authentifiziert haben, führen Sie gh auth login aus.
Befehlszusammenfassung
| Befehl | Purpose |
|---|---|
gh stack init | Initialisieren Sie einen neuen Stapel im aktuellen Repository. |
gh stack add | Fügen Sie oberhalb des aktuellen Stacks einen neuen Branch hinzu. |
gh stack view | Aktuellen Stack anzeigen. |
gh stack checkout | Checken Sie einen Stack anhand der Stack-Nummer, der Pull-Request-Nummer, der Pull-Request-URL oder des Branch-Namens aus. |
gh stack modify | Restrukturieren Sie den aktuellen Stapel interaktiv neu. |
gh stack unstack | Entfernen Sie einen Stapel aus der lokalen Nachverfolgung und legen Sie ihn auf GitHub ab. |
gh stack submit | Übertragen Sie alle Branches und erstellen oder aktualisieren Sie dann Pull Requests und den Stapel auf GitHub. |
gh stack sync | Fetch, Rebase, Push und Synchronisierung des Pull-Request-Status in einem einzigen Befehl. |
gh stack rebase | Pullen Sie vom Remote und führen Sie einen kaskadierenden Rebase über den gesamten Stapel aus. |
gh stack push | Übertragen Sie die aktiven Branches im aktuellen Stack zum Remote-Repository. |
gh stack link | Pull Requests auf GitHub ohne lokales Tracking zu einem Stapel zusammenfassen. |
gh stack merge | Führen Sie einen oder mehrere gestapelte Pull Requests gleichzeitig zusammen. |
gh stack switch | Interaktiver Wechsel zu einer anderen Verzweigung im Stapel. |
gh stack up | Gehen Sie nach oben, in Richtung der Spitze des Stapels, weg vom Trunk. |
gh stack down | Gehen Sie nach unten zum unteren Ende des Stapels, Richtung Trunk. |
gh stack top | Springen Sie zum Anfang des Stapels. |
gh stack bottom | Springen Sie zum unteren Ende des Stapels. |
gh stack trunk | Springen Sie zum Trunkzweig. |
gh stack alias | Erstellen Sie einen kurzen Alias für einen Befehl, damit Sie weniger tippen müssen. |
gh stack feedback | Teilen Sie Feedback zur gh stack Erweiterung. |
Stapelverwaltung
gh stack init
Initialisieren Sie einen neuen Stapel im aktuellen Repository.
gh stack init [flags] [branches...]
Initialisiert lokal einen neuen Stack. Im interaktiven Modus (ohne Argumente) fordert der Befehl zur Eingabe eines Branch-Namens auf und bietet an, den aktuellen Branch als erste Ebene zu verwenden.
Wenn Sie explizite Branch-Namen angeben, werden vorhandene Branches automatisch verwendet und alle fehlenden Branches werden erstellt. Der Trunk ist standardmäßig auf die Standardverzweigung des Repositorys festgelegt, es sei denn, Sie überschreiben ihn mit --base.
In anderen Worktrees ausgecheckte Branches können eingebunden werden. Wenn der Ziel-Branch bereits an anderer Stelle ausgecheckt ist, init lässt Ihren aktuellen Checkout unverändert und meldet stattdessen den zugehörigen Worktree.
Der Befehl aktiviert git rerere automatisch, sodass Konfliktlösungen über mehrere Rebase-Vorgänge hinweg gemerkt werden.
| Flag | Beschreibung |
|---|---|
-b, --base <branch> | Haupt-Branch für den Stack (standardmäßig der Standard-Branch des Repositorys) |
Beispiele:
# Interactive — prompts for branch names
gh stack init
# Non-interactive — specify first branch upfront
gh stack init feature-auth
# Use a different trunk branch
gh stack init --base develop feature-auth
# Adopt or create multiple branches at once
gh stack init feature-auth feature-api feature-ui
gh stack add
Fügen Sie oberhalb des aktuellen Stacks einen neuen Branch hinzu.
gh stack add [flags] [branch]
Erstellt für einen vorhandenen Stapel eine neue Verzweigung am aktuellen HEAD, fügt ihn zum Anfang des Stapels hinzu und checkt ihn aus. Sie müssen diesen Befehl ausführen, während Sie sich am oberen Rand eines Stapels befinden. Wenn Sie keinen Branch-Namen angeben, fordert der Befehl Sie zur Eingabe eines solchen auf.
Wenn der von Ihnen bereitgestellte Branch-Name bereits in einer anderen Arbeitsstruktur ausgecheckt ist, übernimmt add den vorhandenen Branch, ohne einen der beiden Checkouts zu wechseln. Die Commit- und Staging-Shortcuts -m, -A und -u sind mit dieser Art der Übernahme nicht kompatibel, und der Befehl schlägt fehl, bevor etwas gestagt oder die Stack-Zugehörigkeit geändert wird.
Wenn Sie den Befehl interaktiv von einem Branch aus ausführen, der nicht Teil eines Stacks ist, bietet add stattdessen an, einen neuen Stack zu initialisieren. Der von Ihnen angegebene Branch-Name oder der automatisch generierte Name bildet die erste Ebene. Wenn Sie keinen Namen angeben, werden die Standardaufforderungen init verwendet.
Optional können Sie Änderungen stufen und einen Commit als Teil des add Flusses erstellen. Wenn Sie -m ohne expliziten Branch-Namen angeben, wird der Branch-Name automatisch im Datums- und Slug-Format generiert, z. B. 03-24-add_login.
| Flag | Beschreibung |
|---|---|
-A, --all | Alle Änderungen vormerken, einschließlich der nicht verfolgten Dateien. Erfordert -m. |
-u, --update | Stufen Sie Änderungen nur auf nachverfolgte Dateien. Erfordert -m. |
-m, --message <string> | Erstellen eines Commits mit dieser Nachricht vor dem Erstellen der Verzweigung |
Hinweis
-A und -u schließen sich gegenseitig aus.
Beispiele:
# Create a branch by name
gh stack add api-routes
# Prompt for a branch name interactively
gh stack add
# Stage all changes, commit, and auto-generate the branch name
gh stack add -Am "Add login endpoint"
# Stage only tracked files, commit, and auto-generate the branch name
gh stack add -um "Fix auth bug"
# Commit already-staged changes and auto-generate the branch name
gh stack add -m "Add user model"
# Stage all changes, commit, and use an explicit branch name
gh stack add -Am "Add tests" test-layer
# Stage only tracked files, commit, and use an explicit branch name
gh stack add -um "Update docs" docs-layer
gh stack view
Aktuellen Stack anzeigen.
gh stack view [flags]
Zeigt alle Branches im Stack, ihre Reihenfolge, Links zu Pull Requests und den neuesten Commit mit relativem Zeitstempel an. Standardmäßig öffnet der Befehl eine Vollbildansicht in einem interaktiven Terminal und druckt statische Ausgabe in einem nicht interaktiven Terminal. Die Flags --short und --json geben in beiden Umgebungen direkt auf der Standardausgabe aus.
| Flag | Beschreibung |
|---|---|
-s, --short | Kompakte Ausgabe mit einer Zeile pro Branch |
--json | Ausgabestapeldaten als JSON |
Beispiele:
gh stack view
gh stack view --short
gh stack view --json
gh stack view --short verwendet OSC-8-Hyperlinks für Pull-Request-Nummern, wenn das Terminal diese unterstützt. Andernfalls wird die vollständige URL zum Kopieren und Einfügen angezeigt. Legen Sie GH_STACK_HYPERLINKS=1 oder GH_STACK_HYPERLINKS=0 fest, um die Terminalerkennung zu überschreiben.
gh stack checkout
Checken Sie einen Stack anhand seiner Stack-Nummer, einer Pull-Request-Nummer, einer Pull-Request-URL oder eines Branch-Namens aus.
gh stack checkout [<stack-number> | <pr-number> | <pr-url> | <branch>]
| Flag | Beschreibung |
|---|---|
--print-path | Drucken Sie den absoluten Pfad des Ziel-Worktree. Erfordert ein explizites Ziel und fordert nie auf. |
Bei einem Ziel, das in einem anderen Worktree ausgecheckt ist, wird der Pfad des Worktrees gedruckt, --print-path ohne einen der beiden Checkouts zu ändern. Für ein Ziel, das nirgendwo ausgecheckt ist, checkt der Befehl den Branch im aktuellen Worktree aus, bevor er seinen Pfad druckt. Ohne das Flag ist der Versuch, ein Ziel auszuchecken, das an anderer Stelle belegt ist, ein Fehler, der eine Pfad-Diagnosemeldung enthält, anstatt ein erfolgreicher Wechsel zu sein. Details zum Ausgabekontrakt finden Sie in der Navigation.
Eine eigenständige Zahl wird zunächst als Stack- oder Pull-Request-Nummer interpretiert. Hierbei handelt es sich um repositorybezogene Bezeichner, die in der GitHub-UI angezeigt werden. Falls nichts zur Nummer passt, wird sie als Verzweigungsname interpretiert.
Wenn Sie einen Remote-Stack referenzieren, ruft der Befehl den Stack auf GitHub ab, zieht die Branches und richtet den Stack lokal ein. Wenn der Stack bereits lokal vorhanden ist und damit übereinstimmt, wechselt der Befehl zum Branch. Wenn die lokalen und entfernten Stacks unterschiedlich zusammengesetzt sind, werden Sie aufgefordert, den Konflikt zu beheben.
Wenn Sie einen Branch-Namen angeben, prüft der Befehl zuerst die lokal verfolgten Stacks. Wenn der Branch nicht lokal verfolgt wird, sucht der Befehl auf Remote-Stacks nach dem Branch und lädt den entsprechenden Stack herunter. Wenn mehrere Stapel übereinstimmen, verwenden Sie eine Stapel- oder Pullanforderungsnummer, um eine explizit auszuwählen.
Wenn Sie den Befehl ohne Argumente in einem interaktiven Terminal ausführen, prüft er zunächst, ob der aktuelle Branch zu einem Stack auf dem Remote gehört, der lokal nicht nachverfolgt wird, und bietet an, ihn auszuchecken. Wenn es keine eindeutige Übereinstimmung gibt oder Sie dies ablehnen, wird eine durchsuchbare Auswahlliste geöffnet, in der alle für Sie verfügbaren Stacks aufgeführt sind – sowohl die lokal nachverfolgten Stacks als auch die Stacks, die nur auf GitHub vorhanden sind. Jede Zeile zeigt die Stapelnummer, deren untere und obere Verzweigung, Basiszweig, eine Statusleiste, die zusammenfasst, wie viele ihrer Pullanforderungen zusammengeführt, geöffnet, geschlossen oder noch nicht pusht werden und ob der Stapel lokal oder nur auf der Remoteseite verfügbar ist. Filtern Sie mit den Registerkarten "Alle", " Lokal" und " Remote ", oder geben Sie den Suchbegriff ein / . Vollständig zusammengeführte Stapel werden weggelassen. Wenn Sie einen ausschließlich remote vorhandenen Stack auswählen, wird er zunächst lokal geklont, bevor zu ihm gewechselt wird.
Beispiele:
# Check out a stack by its stack number
gh stack checkout 7
# Check out a stack by pull request number
gh stack checkout 42
# Check out a stack by pull request URL
gh stack checkout https://github.com/owner/repo/pull/42
# Check out a stack by branch name
gh stack checkout feature-auth
# Interactive — pick from all available stacks (local and remote)
gh stack checkout
gh stack modify
Restrukturieren Sie den aktuellen Stapel interaktiv neu.
gh stack modify [flags]
Öffnet eine interaktive Terminal-UI zur Umstrukturierung eines Stapels. Alle Änderungen werden auf der Benutzeroberfläche angeordnet und zusammen angewendet, wenn Sie STRG+S drücken. Verzweigungen von zusammengeführten Pullanforderungen können nicht geändert werden.
| Flag | Beschreibung |
|---|---|
--continue | Fortfahren nach dem Auflösen von Konflikten |
--abort | Abbrechen der Änderungssitzung und Wiederherstellen des Stapels in den Zustand, bevor Sie den Befehl ausgeführt haben |
Voraussetzungen
Der Befehl überprüft diese Bedingungen vor dem Öffnen der Schnittstelle:
- Sie müssen lokal einen aktiven Stack ausgecheckt haben.
- Ihre Arbeitsstruktur muss sauber sein, ohne dass keine nicht übernommenen Änderungen vorgenommen werden.
- Es wird keine Neubasis ausgeführt.
- Kein Pull Request im Stack ist zum Zusammenführen vorgemerkt.
- Der Commit-Verlauf muss linear sein, ohne Merge-Commits und ohne auseinandergelaufene Branches.
- Jeder Worktree, der von den gestagten Aktionen und von den Branches benötigt wird, die die Kaskade überleben, muss sauber und frei von anderen Git-Vorgängen sein.
Stack-Branches können über Worktrees verteilt werden. Umbenennungen werden im eigenen Working Tree des Branches ausgeführt. Nach unten gefaltete Cherry-Picks werden im Worktree des empfangenden Branches ausgeführt. Kaskadierende Rebases führen jeden Branch in seinem eigenen Worktree aus. Ein Branch, der nirgendwo ausgecheckt ist, verwendet den Working Tree, von dem aus Sie modify ausgeführt haben, und eingefügte Branches werden als Refs ohne neue Working Trees erstellt. Verworfene und zusammengefaltete Branches und ihre Worktrees bleiben erhalten. Der Trunkzweig wird nur gelesen, sodass nicht verwandte oder unberührte Source-Worktrees keinen sauberen Zustand haben müssen.
Operations
| Operation | Schlüssel | Effect |
|---|---|---|
| Verwerfen | ||
| x | Entfernen Sie den Branch und seine Commits aus dem Stack. Der lokale Branch und der zugehörige Pull Request bleiben erhalten. | |
| Nach unten falten | ||
| d | Absorb setzt sich in die untere Verzweigung hin zum Trunk ein. Der gefaltete Zweig wird aus dem Stapel entfernt. | |
| Hochklappen | ||
| u | Commits in die darüberliegende Branch integrieren, weg vom Trunk. Der gefaltete Zweig wird aus dem Stapel entfernt. | |
| Unten einfügen | ||
| i | Fügen Sie unterhalb des Cursors, zum Stamm hin, einen neuen leeren Zweig ein. | |
| Oben einfügen | ||
| Ich | Fügen Sie oberhalb des Cursors, vom Trunk weg, einen neuen leeren Zweig ein. | |
| Nach unten | ||
| Umschalt+↓ | Verschieben Sie den Zweig nach unten, in Richtung des Stamms. | |
| Nach oben | ||
| UMSCHALT+↑ | Verschieben Sie den Ast nach oben, vom Stamm weg. | |
| Umbenennen | ||
| r | Benennen Sie die Verzweigung mithilfe einer Inlineaufforderung um. | |
| Undo | ||
| Z | Rückgängigmachen der letzten mehrstufigen Aktion. |
Anwendungsphase
Wenn Sie STRG+S drücken, werden die mehrstufigen Änderungen durch Umbenennen von Verzweigungen, Einfügen neuer Verzweigungen, Faltung oder Ablegen von Verzweigungen und Ausführen einer Cascading Rebase angewendet, um einen linearen Commitverlauf mit dem gewünschten Stapelzustand zu erstellen.
Wenn ein Rebase-Konflikt auftritt, können Sie eine der folgenden Aktionen ausführen:
- Lösen Sie die Konflikte, fügen Sie die Dateien zum Staging-Bereich hinzu und führen Sie anschließend
gh stack modify --continueaus. - Führen Sie die Ausführung
gh stack modify --abortaus, um den Vorgang abzubrechen und den Stapel in den vorherigen Zustand wiederherzustellen.
Lösen Sie Konflikte auf und stagen Sie sie in dem in der Konfliktnachricht genannten Worktree, bei dem es sich möglicherweise um den Worktree eines fremden Fold-Receivers oder den eines Rebase-Eigentümers handelt, statt desjenigen, von dem aus Sie modify ausgeführt haben. Sowohl --continue als auch --abort können von jedem verknüpften Worktree aus ausgeführt werden, da sie den gespeicherten Eigentümer anstelle Ihres aktuellen Checkouts verwenden. Fortfahren setzt alle verbleibenden strukturellen Maßnahmen sowie die verbleibenden Rebases fort. Beim Abbrechen werden Umbenennungen in ihren eigenen Worktrees rückgängig gemacht, nur die Refs wiederhergestellt, die der Vorgang berührt hat, und nur die Refs gelöscht, die er erstellt hat. Wenn eine Wiederherstellung oder eine Journal- oder Katalogspeicherung fehlschlägt, wird der Wiederherstellungszustand beibehalten, sodass Sie den Vorgang wiederholen können.
Andere Worktrees werden nie auf einen anderen Branch umgeschaltet. Der Worktree, von dem aus Sie modify ausgeführt haben, kehrt zu seinem ursprünglichen Branch zurück, einschließlich seines neuen Namens, wenn dieser Branch umbenannt wurde, oder zum nächstverfügbaren verbleibenden Branch, wenn der ursprüngliche nicht mehr vorhanden ist. Wenn dieser überlebende Branch an anderer Stelle ausgecheckt ist, behält Ihr Worktree stattdessen seinen erhaltenen ursprünglichen Branch bei, und der Befehl meldet den Pfad des überlebenden Branches. Jeder ausstehende Zustand, der von gh stack submit verwendet wird, wird nur für den Stapel verarbeitet, der gerade geändert wurde.
Nach dem Ändern
Wenn Sie bereits einen Stapel von Pull Requests auf GitHub erstellt haben, führen Sie gh stack submit aus, um die aktualisierten Branches hochzuladen und den Stapel neu zu erstellen. Der alte Stapel wird automatisch ersetzt.
Beispiele:
# Open the interactive modify interface
gh stack modify
# Continue after resolving a conflict
gh stack modify --continue
# Abort and restore to the previous state
gh stack modify --abort
gh stack unstack
Entfernen Sie einen Stapel aus der lokalen Nachverfolgung und legen Sie ihn auf GitHub ab. Dieser Befehl ist auch als gh stack delete verfügbar.
gh stack unstack [<stack-number>] [flags]
Ohne Argument bezieht sich der Befehl auf den aktiven Stack, also den Stack, der den aktuell ausgecheckten Branch enthält. Der Stack auf GitHub wird aufgelöst und das lokale Tracking entfernt.
Geben Sie eine Stapelnummer an, den Bezeichner, der in der Stapelbenutzeroberfläche GitHubangezeigt wird, um einen bestimmten Stapel aufzuheben. Dies funktioniert von überall im Repository aus, unabhängig davon, ob der Stack lokal ausgecheckt ist oder nicht, da der Stack direkt über die GitHub API entstapelt wird. Wenn der Stack auch lokal verfügbar ist, wird auch seine lokale Verfolgung entfernt.
Pull Requests, die bereits zusammengeführt wurden, gerade zusammengeführt werden oder zum Zusammenführen in die Warteschlange eingereiht wurden, können auf GitHub nicht aus einem Stapel entfernt werden und bleiben Teil des Stapels. Wenn jede Pullanforderung entfernt wird, wird der Stapel aufgelöst, und jede lokale Nachverfolgung wird entfernt. Wenn einige Pull-Requests Teil eines Stacks bleiben, wird der Stack beibehalten, und die lokale Tracking-Konfiguration bleibt, sofern vorhanden, unverändert. Verwenden Sie --local, um die Remote-Operation zu überspringen und nur die lokale Tracking-Referenz zu entfernen.
Dieser Befehl ist nützlich, wenn Sie einen Stapel neu strukturieren müssen, indem Sie eine Verzweigung entfernen, eine Verzweigung einfügen, Verzweigungen neu anordnen, Verzweigungen umbenennen oder andere große Änderungen vornehmen. Verwenden Sie nach dem Entstapeln gh stack init, um den Stapel mit der gewünschten Struktur neu zu erstellen. Vorhandene Branches werden automatisch übernommen.
| Flag | Beschreibung |
|---|---|
--local | Entfernen Sie den Stack nur lokal und behalten Sie ihn auf GitHub bei. |
Beispiele:
# Unstack the current stack on GitHub and remove local tracking
gh stack unstack
# Unstack a specific stack by its number
gh stack unstack 7
# Only remove local tracking
gh stack unstack --local
Remotevorgänge
gh stack submit
Übertragen Sie alle Branches und erstellen oder aktualisieren Sie dann Pull Requests und den Stapel auf GitHub.
gh stack submit [flags]
Erstellt eine Pullanforderung für jede Verzweigung im Stapel, wobei Verzweigungen an die Remoteseite verschoben werden. Nach dem Erstellen von Pullanforderungen erstellt submit automatisch auf GitHub einen Stapel, um die Pullanforderungen miteinander zu verknüpfen. Wenn der Stapel auf GitHub bereits vorhanden ist, z. B. aus einer vorherigen Übermittlung, werden neue Pull Requests dem vorhandenen Stapel hinzugefügt.
Wenn jede Pullanforderung im Stapel bereits zusammengeführt wurde, ist dieser Stapel abgeschlossen und kann nicht erweitert werden. In diesem Fall startet submit automatisch einen neuen Stapel, der für Ihre nicht zusammengeführten Branches im Trunk wurzelt, und erstellt ihn auf GitHub, sodass der bereits zusammengeführte Stapel unverändert bleibt.
In einem interaktiven Terminal öffnet submit einen bildschirmfüllenden Editor auf einem einzelnen Bildschirm.
- Linker Bereich. Jeder Branch ohne Pull Request ist standardmäßig eingeschlossen. Wählen Sie alle, die Sie nicht übermitteln möchten, mit STRG+X ab. Da jeder Pull Request auf dem darunterliegenden Branch aufbaut, werden beim Abwählen eines Branches auch die darüber gestapelten Branches abgewählt, und wenn ein Branch wieder einbezogen wird, werden auch die darunterliegenden Branches, von denen er abhängt, wieder einbezogen. Branches, für die bereits ein Pull Request existiert – ob offen, als Entwurf, in der Warteschlange oder zusammengeführt –, werden zur Orientierung angezeigt, sind jedoch gesperrt. Bearbeiten Sie diese im Web.
- Rechtes Panel. Entwerfen Sie für die fokussierte Verzweigung den Titel und die Beschreibung, und wählen Sie aus, ob die Pullanforderung zur Überprüfung oder als Entwurf geöffnet wird. Die Beschreibung wird anhand der Pull-Request-Vorlage Ihres Repositorys oder der Commits vorausgefüllt, einschließlich einer Markdown-Vorschau. Um die Beschreibung in einem externen Editor zu bearbeiten, drücken Sie STRG+E. Die Erweiterung verwendet den ersten nichtleeren Wert aus den Umgebungsvariablen
GH_EDITOR,VISUALundEDITORin dieser Reihenfolge. Wenn nichts festgelegt ist, wirdviverwendet, falls auf IhremPATHverfügbar. Wenn ein gesperrter Zweig fokussiert wird, wird eine schreibgeschützte Karte mit einem Link zum zugehörigen Pull Request angezeigt. Drücken Sie o , um sie im Browser zu öffnen.
Drücken Sie STRG+S , um alle enthaltenen Pullanforderungen gleichzeitig zu übermitteln. Der Editor unterstützt sowohl Tastatur- als auch Mauseingaben. Übergeben Sie --auto, oder führen Sie den Befehl in einem nicht-interaktiven Terminal, etwa in CI, aus, um den Editor zu überspringen und automatisch generierte Titel zu verwenden.
Wenn die Branches bereits offene Pull Requests haben, auf GitHub aber noch kein Stack vorhanden ist, haben Sie die Möglichkeit, die Pull Requests mit STRG+B zu einem Stack zu verknüpfen.
Im Editor sind neue Pull Requests standardmäßig als „bereit zur Überprüfung“ markiert. Sie können jeden Pull Request über die Umschaltfläche als Entwurf markieren. Mit --auto werden neue Pull Requests als Entwurf erstellt, es sei denn, Sie geben --open an.
| Flag | Beschreibung |
|---|---|
--auto | Überspringen des Editors und Verwenden automatisch generierter Pullanforderungstitel |
--open | Erstellen sie neue Pullanforderungen als bereit für die Überprüfung anstelle von Entwürfen, und markieren Sie vorhandene Pullanforderungen als bereit für die Überprüfung. |
--remote <name> | Remote, an die gepusht werden soll (standardmäßig die automatisch erkannte Remote) |
Beispiele:
gh stack submit
gh stack submit --auto
gh stack submit --open
gh stack sync
Fetch, Rebase, Push und Synchronisierung des Pull-Request-Status in einem einzigen Befehl.
gh stack sync [flags]
Synchronisiert den gesamten Stack.
- Abrufen. Ruft die neuesten Änderungen von
originab. - Gleichen Sie den Remote-Stack ab. Spiegelt den Stack auf GitHub lokal wider. Wenn pull-Anforderungen dem Stapel GitHubhinzugefügt wurden, sodass die Remote vor dem lokalen Stapel liegt, werden ihre Verzweigungen automatisch nach unten gezogen und an den lokalen Stapel angefügt. Wenn die lokalen und Remotestapel wirklich voneinander abweichen, z. B. weil Sie eine Verzweigung lokal hinzugefügt haben, während dem Stapel GitHubverschiedene Pullanforderungen hinzugefügt wurden, werden Sie aufgefordert, den Unterschied zu beheben. Siehe "Diverged stacks". In einem nicht-interaktiven Terminal führt eine Divergenz zum Abbruch der Synchronisierung, und es wird weder etwas gepusht noch aktualisiert.
- Schnellvorlauf-Trunk. Leitet die Trunkverzweigung schnell weiter, um mit der Remote zu übereinstimmen. Dieser Schritt wird übersprungen, wenn die Branches divergiert sind.
- Kaskadierungs-Neubasis. Setzt alle Branches im Stapel auf ihre aktualisierten Eltern-Branches neu auf, aber nur, wenn trunk verschoben wurde. Wenn ein Konflikt erkannt wird, werden alle Branches in ihren ursprünglichen Zustand zurückversetzt, und Ihnen wird geraten,
gh stack rebaseauszuführen, um Konflikte interaktiv zu lösen. - Drücken. Pusht alle Branches unter Verwendung von
--force-with-lease, wenn ein Rebase durchgeführt wurde. - Synchronisieren von Pullanforderungen. Synchronisiert den Status von Pull Requests aus GitHub und meldet den Status jedes Pull Requests.
- Synchronisieren Sie den Stapel. Verknüpft die offenen Pull-Requests des Stacks zu einem Stack auf GitHub, erstellt das Remote-Stack-Objekt, falls es noch nicht vorhanden ist, oder aktualisiert es, wenn es nur teilweise erstellt wurde. Dies geschieht nur, wenn zwei oder mehr Pullanforderungen vorhanden sind. Die Synchronisierung öffnet nie Pullanforderungen. Verwenden Sie
gh stack submitdafür. - Löschen. In interaktiven Terminals werden Sie dazu aufgefordert, lokale Branches für zusammengeführte Pull Requests zu löschen. Verwenden Sie
--prune, um automatisch zu löschen.
Ein sauberes Remote-Ahead-Update, bei dem Pull Requests oben auf Ihren lokalen Stack angewendet werden, wird automatisch heruntergeladen, ohne Rückfrage, sodass sync sicher in der Automatisierung ausgeführt werden kann. Synchronisieren Sie Aufforderungen nur, wenn die Stapel tatsächlich auseinandergelaufen sind.
Auseinandergelaufene Stapel
Wenn kein Stapel ein klares Präfix des anderen ist, z. B. weil Sie eine Verzweigung lokal hinzugefügt haben, während separate Pullanforderungen demselben Stapel GitHubhinzugefügt wurden, kann die Synchronisierung die beiden nicht automatisch zusammenführen. In einem interaktiven Terminal bietet es drei Auswahlmöglichkeiten.
- Verwenden Sie den Remote-Stack als maßgebliche Quelle. Ersetzt Ihre lokale Stack-Zusammensetzung durch die des Remotes, wobei alle fehlenden Branches heruntergezogen werden. Wenn Sie sich auf einem Branch befanden, den der Remote-Stack nicht mehr enthält, werden Sie zum nächstgelegenen verbleibenden Branch verschoben. Dies erfordert einen sauberen Arbeitszustand ohne nicht abgeschlossene Änderungen.
- Löschen Sie den Stapel in GitHub. Löscht das Stack-Objekt auf GitHub und beendet die Synchronisierung. Ihre Pull Requests und lokalen Branches bleiben unberührt, und nur der Stack auf GitHub wird entfernt. Erstellen Sie den Stack mit
gh stack submitneu; führen Sie zuerstgh stack modifyaus, wenn Sie seine Struktur ändern möchten. So sorgen Sie dafür, dass GitHub zu Ihrem lokalen Stack passt, dennsubmiterstellt im Gegensatz zusyncauch Pull-Requests für alle Branches, die Sie noch nicht eingereicht haben.