Ein Stapel ist eine Reihe von Pullanforderungen im selben Repository, in dem jede Pullanforderung auf die Verzweigung der Pullanforderung darunter ausgerichtet ist und eine geordnete Kette bildet, die in einer einzelnen Verzweigung landet, in der Regel Ihre Hauptzweige. Anstelle einer großen Pullanforderung erhalten Sie eine Reihe kleinerer Pullanforderungen. Da jede Pullanforderung über einen eigenen diff mit Relevanz verfügt, können Teamkollegen jede Ebene unabhängig überprüfen und genehmigen.
Jeder Pull Request in einem Stack wird anhand von Regeln für die Basis des Stacks ausgewertet – in der Regel main – unabhängig davon, auf welche Verzweigung er direkt ausgerichtet ist. Dies bedeutet, dass Mid-Stack-Pull Requests denselben Standards entsprechen wie der untere Pull Request.
Hinweis
- Gestapelte Pullanforderungen erfordern, dass sich alle Verzweigungen im selben Repository befinden. Kreuzverzweigungsstapel werden nicht unterstützt.
- Gestapelte Pullanforderungen werden in GitHub Desktop.
Verfügbarkeit gestapelter Pull Requests
Die gh stackGitHub CLI Erweiterung unterstützt den lokalen Entwicklungsworkflow. Es erstellt und verfolgt Verzweigungen in der richtigen Abhängigkeitsreihenfolge, hält Branches rebased, pusht Verzweigungen, erstellt und verknüpft Pull Requests und navigiert zwischen Ebenen.
GitHub CLI ist nicht erforderlich. Die zugrunde liegenden Git-Vorgänge sind standard, und Sie können stattdessen Stapel von der GitHub Website erstellen.
Wenn Sie andere Tools wie Jujutsu oder Sapling verwenden, um Ihre lokalen Branches zu verwalten und zu pushen, können Sie weiterhin GitHub CLI oder die GitHubWebsite verwenden, um einen Stapel von Pull Requests aus diesen Branches zu öffnen. Siehe Andere Tools mit gestapelten Pull-Requests verwenden.
Trunks für gestapelte Pull Requests
Der Trunk eines Stapels ist der Basiszweig des untersten Pull Request. Jede andere Pull Request im Stapel basiert darauf. Der Trunk ist standardmäßig auf die Standardverzweigung Ihres Repositorys festgelegt, z. B. main, kann aber jede beliebige Verzweigung sein, z. B. ein Release-Branch oder ein langlebiger Feature-Branch.
Trunk festlegen:
- Ab GitHub CLI geben Sie die Option
--base BRANCHan den Befehlgh stack initweiter (z. B.gh stack init --base release auth-layer). - Erstellen Sie auf der GitHub Website den unteren Pull Request gegen den Branch, den Sie als Trunk verwenden möchten. Der Rest des Stacks baut darauf auf.
Verzweigungsschutzregeln, erforderliche Prüfungen und CI werden alle gegen den Ziel-Branch des Stacks ausgewertet, nicht nur gegen Ihren Standardzweig.
Branch-Schutzregeln und erforderliche Statuschecks
Im Folgenden werden alle so bewertet, als ob jeder Pull Request auf die Stack-Basis abzielt, nicht auf den Branch direkt darunter:
| Regel | Wie sie bewertet wird |
|---|---|
| Erforderliche Überprüfungen | An der Stack-Basis ausgewertet. |
| Erforderliche Statusüberprüfungen | An der Stack-Basis ausgewertet. |
| CODEOWNERS | Von der Stack-Basis aus ausgewertet. Änderungen an CODEOWNERS in einem unteren Pull Request wirken sich nicht auf Pull Requests darüber aus. |
| Code-Scanning-Workflows | Gegen den Stack-Beginn ausgewertet. |
GitHub Actions
GitHub Actions-Workflows werden ausgelöst, als ob jeder Pull Request im Stapel auf die Basis des Stapels abzielt. Ein Workflow, der so konfiguriert ist, dass er bei pull_request-Ereignissen mit Ziel main ausgeführt wird, läuft für jeden Pull Request im Stack, nicht nur für den untersten, sodass keine Workflowänderungen erforderlich sind.
Stack-Metadaten, z. B. der Basis-Branch des Stacks, stehen in Workflowausdrücken über github.event.pull_request.stack zur Verfügung. Diese Eigenschaft ist nur vorhanden, wenn der Pull Request zu einem Stack gehört.
Den vollständigen Satz von Metadatenfeldern und -mustern zur Reduzierung der redundanten CI-Verwendung finden Sie unter Optimieren von CI für gestapelte Pull Requests.
Rebasing
Wenn ein Rebase verfügbar oder erforderlich ist, zeigt das Merge-Feld dies an, indem eine Schaltfläche „Rebase-Stack“ angezeigt wird. Dies kann beispielsweise passieren, wenn Änderungen an einem Pull Request den Stack nicht linear machen. Wenn die untere Pull Request zusammengeführt wird, wird automatisch ein Rebase durchgeführt, und normalerweise müssen Sie kein Rebase manuell durchführen.
Wenn ein Stack neu basiert wurde, können Sie Folgendes erwarten:
- Durch das erneute Rebasen des Stacks werden signierte Commits generiert.
- Das Neubasieren eines Stapels zählt nicht als neuer, überprüfbarer Commit, wenn sich der Diff nicht ändert. Genehmigungen werden in diesem Fall beibehalten, auch wenn die Veraltete Pull-Request-Genehmigungen verwerfen, wenn neue Commits übertragen werden-Regel aktiviert ist.
Merge-Anforderungen
Bevor ein Pull Request in einem Stack zusammengeführt werden kann, muss Folgendes erfüllt sein:
- Der Pull Request erfüllt jede Anforderung des Branch-Schutzes für die Stack-Basis, einschließlich erforderlicher Überprüfungen, erforderlicher Statusprüfungen und CODEOWNER-Genehmigungen.
- Alle Pull Requests darunter im Stapel erfüllen auch diese Anforderungen.
- Der Stack weist eine vollständig lineare Historie zwischen seinen Branches auf.
Im Stapel main ← PR1 ← PR2 ← PR3 erfordert das Zusammenführen von PR #3, dass PR #1 und PR #2 ebenfalls Prüfungen bestehen, die erforderlichen Reviews haben und alle Branch-Schutzregeln erfüllen.
Hinweis
Gestapelte Pull Requests unterstützen das Zusammenführen mit Regeln zum Umgehen, aber nur der unterste Pull Request kann auf diese Weise zusammengeführt werden. Sie können den gesamten Stapel nicht mit Umgehungsregeln zusammenführen. Weitere Informationen findest du unter Erstellen von Regelsätzen für ein Repository.
Methoden zusammenführen
Stacks unterstützen alle drei Zusammenführungsmethoden. In jedem Fall landen die Pull-Requests als eine einzelne atomare Operation:
- Merge commit erstellt einen Zusammenführungs-Commit für jede zusammengeführte Pullanforderung, wobei der vollständige Commitverlauf jeder Pullanforderung erhalten bleibt.
- Squash erstellt einen sauberen Squash-Commit pro Pull-Anforderung. Durch das Zusammenführen von
nPull Requests werdennSquash-Commits auf dem Basis-Branch erstellt. - Rebase wendet die Commits aus jedem Pull Request erneut auf dem Basis-Branch an, wodurch ein linearer Verlauf ohne Merge-Commits erstellt wird.
Zusammenführen über eine Merge-Warteschlange
Stacks unterstützen Merge-Warteschlangen vollständig. Alle Pull Requests im Stack werden der Warteschlange in der richtigen Reihenfolge hinzugefügt. Wenn ein Pull Request aus der Warteschlange entfernt oder ausgeworfen wird, werden auch alle Pull Requests darüber im Stack entfernt.
Hinweis
Um einen Stapel zusammenzuhalten, erlaubt die Zusammenführungswarteschlange, dass die Zusammenführungsgruppe ihre konfigurierte maximale Größe um bis zu 50 Prozent überschreitet. Wenn der Stapel zu groß ist, um in diesen Puffer zu passen, wird er automatisch als einzelne Einheit in die nächste Zusammenführungsgruppe eingefügt.
Lineare Historie
Ein vollständig linearer Verlauf zwischen jeder Verzweigung im Stack ist eine strenge Anforderung für das Mergen. Ein Stack kann seinen linearen Verlauf verlieren, wenn Änderungen auf einen unteren Branch gepusht werden oder wenn der Trunk voranschreitet.
Führen Sie zum Wiederherstellen eines linearen Verlaufs einen kaskadierenden Rebase aus:
- Über die CLI — führen Sie
gh stack rebaseaus, und pushen Sie dann mitgh stack push. - Klicken Sie auf der GitHub Website im Merge-Feld auf "Rebase stack", um ein serverseitiges kaskadierendes Rebase auszulösen.
Anweisungen findest du unter Verwalten von gestapelten Pull Requests.