Konfigurieren von Zielzweigen für Pullanforderungen

Azure DevOps Services

Standardmäßig schlägt Azure DevOps die Erstellung neuer Pullanforderungen für die Standardbranch vor. In einem Repository mit mehreren Verzweigungen, die für Pullanforderungen verwendet werden, können Repositorybesitzer die Liste der Pullanforderungsziel-Verzweigungen konfigurieren, damit diese Vorschläge die richtige Zielzweige 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 Titel pull_request_targetsenthalten, 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 gibt main als Zielzweig an, der zuerst ausgewählt werden soll, aber wenn eine Verzweigung beginnt release/ oder feature/ eine bessere Wahl ist, wird stattdessen diese Verzweigung 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-Anforderungen. Wenn ein Benutzer eine Verzweigung an Azure DevOps überträgt, schlägt der nächste Besuch der Seite "Repos" möglicherweise vor, eine Pullanforderung aus dieser Verzweigung 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.

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 Verzweigungen enthält, die durch Pullanforderungsrichtlinien 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 den Commit dar, der in die Ziel-Verzweigung eingeführt wird, indem eine Pullanforderung abgeschlossen wird und das erste übergeordnete Element der vorherige Tipp ist.

Wie wählt Azure DevOps eine Verzweigung aus?

Git verfolgt metadaten nicht um die Erstellung einer Verzweigung. 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 Zielverzweigungen wählt Azure DevOps die Verzweigung aus, deren erster übergeordneter Verlauf sich mit dem ersten übergeordneten Verlauf der Quellverzweigung am meisten überschneidet.

Beispiel: Keine Zusammenführungs-Commits

Betrachten Sie die folgende Verzweigungsstruktur, die einfacher als normal ist, da keine Zusammenführungs-Commits vorhanden sind. In diesem Beispiel wird der gesamte Verlauf durch den ersten übergeordneten 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 Kandidatenzielzweige in Der Reihenfolge der Priorität:

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

Der Quellzweig wird topicdann mit diesen Verzweigungen verglichen.

• main schneidet sich mit topic at B, verlassen G,I und topic nicht in main.
• release/2024-September schneidet sich mit topicA dem Verlassen B,G,I in topic und nicht in release/2024-September.
• feature/targets schneidet sich mit topic at G, verlassen I und topic nicht in feature/targets.

Daher wird die feature/targets Verzweigung in diesem Beispiel als Zielzweig für eine Pullanforderung als topic Quellzweig ausgewählt.

Beispiel: Zusammenführen von Commits

In einem komplizierteren Beispiel, bei dem die feature/targets Verzweigung mit sich selbst zusammengeführt main und zusammengeführt main 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-In Dmain eine Zeit dar, feature/targets zu mainder zusammengeführt wurde. Commit M stellt eine Zeit dar, zu mainder feature/targets zusammengeführt wurde. Die Verknüpfung zwischen Commits M und J wird auf eine Weise gezeichnet, um hervorzuheben, dass J das zweite übergeordnete Element der M Zeit L das erste übergeordnete Element ist.

In diesem Fall, wenn Sie den vollständigen Commit-Verlauf betrachten und mainfeature/targets beide den Verlauf von topic at Güberschneiden. Der erste übergeordnete Verlauf zeigt jedoch weiterhin eine Einstellung für feature/targets.

Bruchbindungen

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, z. B. den Beginn einer neuen Featurebranch oder die Verzweigung einer Release-Verzweigung.

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

In diesem Beispiel wurde die release/2024-October Verzweigung aus der main Verzweigung erstellt, nachdem topic sie mainabzweigt 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 einen Selektor zum Anpassen der Ziel-Verzweigung, 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 Zielverzweigungen willkürlich verschoben werden können, ist der Verlauf des ersten übergeordneten Elements kein zuverlässiger Indikator für den vorherigen Standort dieser Verzweigung.

• 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 und git commitgit 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 der von dieser Heuristik ausgewählten Zielzweig nicht einverstanden sind, sollten Sie die Auswahl mithilfe git rebase --onto <new-target> <old-target> <source>der Option 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 der falschen Verzweigung basieren, besteht git merge darin, den richtigen Zweig in ihre Geschichte zu bringen. Das Zusammenführen ändert nicht den Verlauf des ersten übergeordneten Elements und ändert daher nicht die Auswahl für die Zielverzweigung.

Wie kann ich diese Entscheidung lokal testen?

Die heuristische Verwendung von Azure DevOps wurde zum Zentralen Git-Client beigetragen 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 zuerst aus git fetch origin , um sicherzustellen, dass Sie über die neueste Version der Zielzweige 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 vergleicht den ersten übergeordneten Verlauf der Zielverzweigungen auf die gleiche Weise. 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

• Ändern des Standardbranches
• Erstellen von Pull Requests
• Anzeigen von Pull Requests
• Übersicht zu Pull Requests
• Abschließen von Pull Requests
• Mehrere Mergebasen