Konfigurieren von Zielzweigen für Pullanforderungen

Azure DevOps Services

Standardmäßig schlägt Azure DevOps die Erstellung neuer Pull-Anfragen für die Standard-Branch vor. In einem Repository mit mehreren Branches, die für Pull-Anfragen verwendet werden, können Repositorybesitzer die Liste der Pull-Anfrage-Zielbranches konfigurieren, damit diese Vorschläge den richtigen Zielzweig auswählen.

Um dieses Feature zu aktivieren, erstellen Sie eine Datei mit dem Namen .azuredevops/pull_request_targets.yml im Standardbranch des Repositorys. Diese YAML-Datei sollte eine einzelne Liste mit dem Namen pull_request_targets enthalten, die die Verzweigungsnamen oder Präfixe enthält, die den Kandidatenzweigen entsprechen.

Betrachten Sie z. B. die folgenden Inhalte:

pull_request_targets:
  - main
  - release/*
  - feature/*

Diese Liste potenzieller Ziele spezifiziert main als den zuerst auszuwählenden Ziel-Branch. Sollte jedoch ein Branch, der mit release/ oder feature/ beginnt, eine bessere Wahl sein, wird stattdessen dieser Branch ausgewählt.

Weitere Überlegungen zu Pullanforderungsrichtlinien und -verwaltung finden Sie unter "Informationen zu Pullanforderungen".

Voraussetzungen

Wann wird diese Konfiguration verwendet?

Es gibt mehrere Einstiegspunkte für die Verwendung eines dynamischen Zielzweigs.

• Vorschläge für Pull Requests. Wenn ein Benutzer einen Branch zu Azure DevOps überträgt, schlägt der nächste Besuch der Repos-Seite möglicherweise vor, einen Pull-Request aus diesem Branch zu erstellen. Diese Schaltfläche "Neue Pullanforderung erstellen" wählt den Zielzweig dynamisch aus.

• URL der Pullanforderung. Wenn ein Benutzer mithilfe eines sourceRef Parameters direkt zur Erstellungsseite der Pullanforderung navigiert, aber den targetRef Parameter ausgelassen, wählt Azure DevOps basierend auf dieser dynamischen Auswahl einen Zielzweig aus.

• Branch-Dropdown Wenn ein Benutzer die Verzweigungsdropdowns in Azure DevOps öffnet, werden die in den Pullanforderungszielen angegebenen Verzweigungen in einem Abschnitt namens "Ziele" zwischen den Abschnitten "Mine" und "All" angezeigt.

  

Es gibt eine Möglichkeit für Clienttools, Pullanforderungen mithilfe dieser dynamischen Wahl zu erstellen, aber diese Clients müssen ein optionales Signal hinzufügen, dass der Benutzer keinen Zielzweig angegeben hat. Überprüfen Sie ihr Clienttool, um festzustellen, ob die Option aktiviert ist.

Was sind gute Kandidaten für Zweigziele?

Es wird empfohlen, dass die konfigurierte Liste der Kandidatenzweige nur Zweige enthält, die durch Pull-Request-Richtlinien geschützt sind. Solche Verzweigungen werden wahrscheinlich nur geändert, indem Pullanforderungen abgeschlossen werden, wodurch sichergestellt wird, dass sich die vorherige Verzweigungsposition im ersten übergeordneten Verlauf des Tipp-Commits befindet. Wenn eine Zusammenführungsstrategie verwendet wird, stellt das zweite übergeordnete Element die Commits dar, die durch das Abschließen einer Pull-Anfrage in die Zielverzweigung eingeführt werden, und das erste übergeordnete Element ist die vorherige Spitze.

Wie wählt Azure DevOps einen Zweig aus?

Git verfolgt keine Metadaten beim Erstellen eines Branches. Es gibt keine genaue Möglichkeit, zu bestimmen, welche Verzweigung beim Erstellen einer Themenzweigung verwendet wurde. Stattdessen verwendet Azure DevOps eine Heuristik basierend auf der ersten übergeordneten Geschichte der Filialen.

Unter den möglichen Ziel-Branches wählt Azure DevOps den Branch aus, dessen First-Parent-Historie sich am meisten mit der First-Parent-Historie der Quell-Branch überschneidet.

Beispiel: Keine Zusammenführungs-Commits

Betrachten Sie die folgende Verzweigungsstruktur, die stärker vereinfacht als normal ist, da keine Merge-Kommandos vorhanden sind. In diesem Beispiel wird die gesamte Historie durch den ersten Elternteil-Verlauf dargestellt.

  ,-E---F <-- release/2024-September
 /
A---B---C---D <--- main
     \
      `-G---H <--- feature/targets
         \
          `-I <--- topic

Mit diesem Verlauf und der zuvor verwendeten Beispielliste pull_request_targets haben wir drei mögliche Zielzweige in der Reihenfolge der Priorität:

• main
• release/2024-September
• feature/targets

Der Quellzweig wird topicdann mit diesen Verzweigungen verglichen.

• main schneidet topic an B, wobei G,I in topic bleibt und nicht in main.
• release/2024-September schneidet topic bei A, wodurch B,G,I in topic verbleibt und nicht in release/2024-September.
• feature/targets schneidet sich mit topic bei G, wodurch I in topic bleibt und nicht in feature/targets.

Daher wird der feature/targets Branch in diesem Beispiel als Zielbranch für einen Pull Request mit topic als Source Branch ausgewählt.

Beispiel: Zusammenführen von Commits

In einem komplizierteren Beispiel, bei dem der Branch feature/targets in main und main in sich selbst zusammengeführt wurde, hat der Commit-Verlauf mehr Fälle zu berücksichtigen:

  ,-E---F <-- release/2024-September
 /
A---B---C---D---J---K <--- main
     \    _/     \
      \  /        \
       `G---H---L--\--M <--- feature/targets
         \          \/
          \
           `I <--- topic

Hier stellt der Commit D in main einen Zeitpunkt dar, an dem feature/targets in main zusammengeführt wurde. Commit M kennzeichnet einen Moment, in dem main in feature/targets zusammengeführt wurde. Die Verbindung zwischen den Commits M und J wird so gezeichnet, dass hervorgehoben wird, dass J das zweite Eltern-Commit von M ist, während L das erste Eltern-Commit ist.

In diesem Fall, wenn Sie den vollständigen Commit-Verlauf betrachten, schneiden sowohl main als auch feature/targets den Verlauf von topic bei G. Der erste übergeordnete Verlauf zeigt jedoch weiterhin eine Vorliebe für feature/targets.

Verbindungen trennen

Wenn zwei Verzweigungen dieselbe Schnittmenge des ersten übergeordneten Verlaufs aufweisen, wählt Azure DevOps die Verzweigung aus, die weiter oben in der pull_request_targets Liste angezeigt wird. Wenn mehrere Verzweigungen basierend auf der pull_request_targets Liste aufgrund einer Präfix-Übereinstimmung noch gebunden sind, gewinnt die früheste alphabetische Reihenfolge.

Diese Arten von Bindungen sind am häufigsten vorhanden, wenn neue Kandidatenzweige erstellt werden, wie etwa zu Beginn eines neuen Feature-Zweigs oder bei der Abzweigung eines Release-Zweigs.

          ,-E---F <-- release/2024-October
         /
A---B---C---D <--- main
     \
      \
       `G <--- topic

In diesem Beispiel wurde die release/2024-October-Branch von der main-Branch erstellt, nachdem die topic von der main abgezweigt wurde. Dies ist zwar intuitiv für einen menschlichen Leser, aber die Reihenfolge der main Kategorien release/* in der pull_request_targets Liste gibt die bevorzugte Reihenfolge für Azure DevOps an.

Was geschieht, wenn Azure DevOps den falschen Zielzweig auswähle?

Die Seite zum Erstellen von Pullanforderungen verfügt über ein Auswahlfeld zum Anpassen des Ziel-Branches, wenn die dynamische Auswahl nicht den Erwartungen entspricht. Der Zielzweig kann auch angepasst werden, nachdem die Pullanforderung erstellt wurde.

Wichtiger ist, dass es hilfreich sein kann zu verstehen, warum die Heuristik die "falsche" Zielzweige auswählen kann.

Diese Heuristik basiert auf einigen Annahmen darüber, wie die Zielzweige und der Quellzweig erstellt wurden. Hier sind einige mögliche Gründe, warum die Heuristik nicht funktioniert:

• Die Zielzweige sind nicht durch Pullanforderungsrichtlinien geschützt. Wenn die Ziel-Branches beliebig gepusht werden können, ist die First-Parent-Historie kein zuverlässiger Indikator für den früheren Stand dieses Branches.

• Der Quellzweig wurde aus einem vorherigen Tipp eines Kandidatenzweigs erstellt. Wenn der Quellzweig einen beliebigen Commit im Verlauf ausgewählt hat, gibt es keine Garantie für den ersten übergeordneten Verlauf, von dem er abhängt.

• Der Quellzweig wurde mithilfe der git commit und git merge Befehle erweitert. Befehle wie git reset --hard z. B. oder git rebase können den Verlauf der Verzweigung auf unvorhersehbare Weise ändern.

Wenn Sie mit dem Zweigziel, das von der Heuristik ausgewählt wurde, nicht einverstanden sind, sollten Sie die Auswahl mithilfe von git rebase --onto <new-target> <old-target> <source> aktualisieren. Der git rebase Befehl schreibt den ersten übergeordneten Verlauf um, damit die Heuristik das neue Ziel auswählen kann.

Ein häufiger Fehler, den Benutzer machen, wenn sie feststellen, dass sie auf dem falschen Branch arbeiten, besteht darin, git merge zu verwenden, um den richtigen Branch in ihre Versionshistorie zu integrieren. Das Zusammenführen ändert nicht den Verlauf des ersten Elternteils und daher nicht die Auswahl des Ziel-Branches.

Wie kann ich diese Entscheidung lokal testen?

Die Heuristik von Azure DevOps wurde in den Git-Kernclient eingeführt und ist in Git-Versionen 2.47.0 und höher verfügbar.

Um diese Logik in Ihrem eigenen Repository zu testen, führen Sie git fetch origin zuerst aus, um sicherzustellen, dass Sie über die neueste Version der Ziel-Branches verfügen. Führen Sie dann den folgenden git for-each-ref Befehl aus, der an Ihre Liste der Kandidatenzweige angepasst ist:

$ git for-each-ref --format="%(is-base:HEAD) %(refname)" \
           refs/remotes/origin/main \
           "refs/remotes/origin/release/*" \
           "refs/remotes/origin/feature/*"
 refs/remotes/origin/main
 refs/remotes/origin/release/2024-September
(HEAD) refs/remotes/origin/feature/targets

In diesem Befehl wird der HEAD Commit als Quelle verwendet und die erste-Eltern-Historie der Zielzweige wird in gleicher Weise verglichen. Während jeder Kandidatenzweig in der Ausgabe aufgeführt ist, gibt die Zeichenfolge (HEAD) an, welche der Verzweigungen als Zielzweig verwendet werden soll.

Nächste Schritte

Verwandte Artikel

• Den Standardzweig ändern
• Erstellen von Pull Requests
• Anzeigen von Pull Requests
• Übersicht zu Pull Requests
• Pull-Anfragen abschließen
• Mehrere Mergebasen