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 Titel pull_request_targetsenthalten, die die Namen oder Präfixe der Zweige 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 Zweig an Azure DevOps schiebt, kann sein nächster Besuch auf der Repos-Seite vorschlagen, eine Pull-Anforderung aus diesem Zweig 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.

• Verzweigungsdropdown Wenn ein Benutzer das Verzweigungsdropdown in Azure DevOps öffnet, werden die in den Pullanforderungszielen angegebenen Verzweigungen in einem Abschnitt namens "Ziele" zwischen den Abschnitten "Meine" und "Alle" 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 Zweige werden wahrscheinlich nur durch das Ausfüllen von Pull-Requests geändert, was garantiert, dass sich die vorherige Zweigstelle in der Vorgängerhistorie des TIP-Commits befindet. Wenn eine Merge-Strategie verwendet wird, dann repräsentiert das zweite übergeordnete Element die Commits, die in den Zielzweig eingeführt werden, indem eine Pull-Anforderung abgeschlossen wird, und das erste übergeordnete Element ist der vorherige Tipp.

Wie wählt Azure DevOps einen Zweig aus?

Git verfolgt keine Metadaten rund um die Erstellung eines Zweigs. Es gibt keine genaue Möglichkeit, festzustellen, welcher Zweig beim Erstellen eines Themenzweigs verwendet wurde. Stattdessen verwendet Azure DevOps eine Heuristik, die auf der Historie der Zweige des ersten Elternteils basiert.

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 Merge-Commits

Betrachten Sie die folgende Zweigstruktur, die mehr als normal vereinfacht wird, da es keine Merge Commits gibt. In diesem Beispiel wird der gesamte Verlauf durch den Verlauf des ersten Elternteils 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 topic an G, wobei 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 die Verzweigung 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. Die erste Elterngeschichte zeigt jedoch immer noch eine Präferenz für feature/targets.

Verbindungen trennen

Wenn zwei Verzweigungen denselben Schnittpunkt in der Historie des ersten übergeordneten Elements haben, wählt Azure Devops die Verzweigung aus, die früher in der pull_request_targets Liste erscheint. Wenn mehrere Zweige auf der Grundlage der pull_request_targets -Liste aufgrund einer Präfix-Übereinstimmung immer noch gleich sind, dann gewinnt der früheste in alphabetischer Reihenfolge.

Diese Arten von Bindungen sind am häufigsten vorhanden, wenn neue Kandidatenzweige erstellt werden, z. B. der Beginn eines neuen Featurezweigs oder die Gabelung eines Releasezweigs.

          ,-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 Zielverzweigungen beliebig gepusht werden können, ist der Verlauf des ersten übergeordneten Elements kein zuverlässiger Indikator für den früheren Ort dieser Verzweigung.

• Der Quellzweig wurde aus einem vorherigen Tipp eines Kandidatenzweigs erstellt. Wenn der Quellbranch einen beliebigen Commit in der Historie ausgewählt hat, gibt es keine Garantie für die erste übergeordnete Historie, von der er abhängig war.

• 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 der Zielverzweigung, die 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 Verlauf des ersten übergeordneten Elements 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 somit auch nicht die Auswahl für den Zielzweig.

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 vergleicht die First Parent History der Zielzweige 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

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