Richtlinien und Einstellungen von Verzweigungen

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Branchrichtlinien helfen Teams dabei, ihre wichtigen Branches der Entwicklung zu schützen. Richtlinien erzwingen die Codequalitäts- und Change Management-Standards Ihres Teams. In diesem Artikel wird beschrieben, wie Branchrichtlinien festgelegt und verwaltet werden. Eine Übersicht über alle Repository- und Branchrichtlinien und -einstellungen finden Sie unter Festlegen von Git-Repositoryeinstellungen und -Richtlinien.

Ein Branch, für den die erforderlichen Richtlinien konfiguriert sind, kann nicht gelöscht werden und erfordert Pull Requests (PRs) für alle Änderungen.

Voraussetzungen

  • Zum Festlegen von Branchrichtlinien müssen Sie Mitglied der Sicherheitsgruppe „Projektadministratoren“ sein oder über die Berechtigungen Richtlinien bearbeiten auf Repositoryebene verfügen. Weitere Informationen finden Sie unter Festlegen von Git-Repositoryberechtigungen.

Konfigurieren von Branchrichtlinien

Zum Verwalten von Branchrichtlinien wählen Sie Repos>Branches aus, um die Seite Branches im Webportal zu öffnen.

Screenshot: Menüelement „Branches“

Zu den Einstellungen für die Branchrichtlinien gelangen Sie auch über Projekteinstellungen>Repository>Richtlinien>Branchrichtlinien><Branchname>.

Branches, für die Richtlinien gelten, zeigen ein Richtliniensymbol an. Sie können das Symbol auswählen, um direkt zu den Einstellungen der Branchrichtlinie zu gelangen.

Zum Festlegen von Branchrichtlinien suchen Sie den Branch, den Sie verwalten möchten. Sie können die Liste durchsuchen oder im Feld Branchname suchen oben rechts nach Ihrem Branch suchen.

Wählen Sie das Symbol Weitere Optionen neben dem Branch und dann die Option Branchrichtlinien im Kontextmenü aus.

Screenshot: Öffnen der Branchrichtlinien über das Kontextmenü

Suchen Sie Ihren Branch auf der Seite. Sie können die Liste durchsuchen oder den Branch im Feld Alle Branches durchsuchen oben rechts suchen.

Screenshot: Seite „Branches“

Wählen Sie die Schaltfläche ... aus. Wählen Sie im Kontextmenü Branch Policies (Branchrichtlinien) aus.

Screenshot: Öffnen der Branchrichtlinien über das Kontextmenü

Konfigurieren Sie die Richtlinien auf der Seite mit den Einstellungen für den Branch. In den folgenden Abschnitten finden Sie Beschreibungen und Anleitungen zu den einzelnen Richtlinienarten.

Konfigurieren Sie die Richtlinien auf der Seite Policies (Richtlinien). In den folgenden Abschnitten finden Sie Beschreibungen zu den einzelnen Richtlinienarten. Wählen Sie Änderungen speichern aus, um Ihre neue Richtlinienkonfiguration anzuwenden.

Screenshot: Registerkarte „Richtlinien“

Mindestanzahl von Reviewern erforderlich

Code Reviews sind wichtig für Softwareentwicklungsprojekte. Um sicherzustellen, dass Teams PRs überprüfen und genehmigen, können Sie die Genehmigung einer Mindestanzahl von Reviewern anfordern. Die grundlegende Richtlinie erfordert, dass eine bestimmte Anzahl von Reviewern den Code ohne Ablehnungen genehmigen muss.

Um die Richtlinie festzulegen, legen Sie unter Branchrichtlinien die Option Mindestanzahl von Reviewern erfordern auf Ein fest. Geben Sie die erforderliche Anzahl von Reviewern ein, und wählen Sie eine der folgenden Optionen aus:

Screenshot: Richtlinie „Erforderliche Code Reviews aktivieren“

  • Wählen Sie Anforderern die Genehmigung eigener Änderungen gestatten aus, damit der PR-Ersteller über dessen Genehmigung abstimmen kann. Andernfalls kann der Ersteller immer noch mit Genehmigen über den PR abstimmen, aber seine Stimme zählt nicht für die Mindestanzahl der Reviewer.

  • Wählen Sie Letzte Push ausführende Person daran hindern, eigene Änderungen zu genehmigen aus, um eine Aufgabentrennung zu erzwingen. Standardmäßig kann jeder, der über die Push-Berechtigung für den Quellbranch verfügt, sowohl Commits hinzufügen als auch über die Genehmigung von PRs abstimmen. Wenn Sie diese Option auswählen, wird die Stimme der Person, die den letzten Push ausgeführt hat, nicht gezählt, auch wenn sie ihre eigenen Änderungen einfach genehmigen können.

  • Wählen Sie Fertigstellung zulassen, auch wenn einige Reviewer „Warten“ oder „Ablehnen“ auswählen aus, um den PR-Abschluss zuzulassen, auch wenn einige Reviewer gegen die Genehmigung stimmen. Die Mindestanzahl der Reviewer muss weiterhin zustimmen.

  • Unter Beim Pushen neuer Änderungen:
    • Aktivieren Sie Mindestens eine Genehmigung für die letzte Iteration erforderlich, um mindestens eine Genehmigungsstimme für die letzte Änderung am Quellbranch zu erfordern.
    • Aktivieren Sie Alle Genehmigungsstimmen zurücksetzen (Stimmen werden nicht auf „Ablehnen“ oder „Warten“ zurückgesetzt), um alle Genehmigungsstimmen zu entfernen, aber die Stimmen zum Ablehnen oder Warten beizubehalten, wenn sich der Quellbranch ändert.
    • Aktivieren Sie Alle Codereviewerstimmen zurücksetzen, um alle Reviewerstimmen zu entfernen, wenn sich der Quellbranch ändert, einschließlich der Stimmen zum Genehmigen, Ablehnen oder Warten.
  • Unter Beim Pushen neuer Änderungen:
    • Aktivieren Sie Mindestens eine Genehmigung für jede Iteration erforderlich, um mindestens eine Genehmigungsstimme für die letzte Änderung am Quellbranch zu erfordern. Die Genehmigung des Benutzers wird nicht auf alle vorherigen nicht genehmigten Iterationen gezählt, die von diesem Benutzer gepusht wurden. Daher ist eine zusätzliche Genehmigung für die letzte Iteration von einem anderen Benutzer erforderlich. Mindestens eine Genehmigung für jede Iteration erforderlich ist in Azure DevOps Server 2022.1 und späteren Versionen verfügbar.
    • Aktivieren Sie Mindestens eine Genehmigung für die letzte Iteration erforderlich, um mindestens eine Genehmigungsstimme für die letzte Änderung am Quellbranch zu erfordern.
    • Aktivieren Sie Alle Genehmigungsstimmen zurücksetzen (Stimmen werden nicht auf „Ablehnen“ oder „Warten“ zurückgesetzt), um alle Genehmigungsstimmen zu entfernen, aber die Stimmen zum Ablehnen oder Warten beizubehalten, wenn sich der Quellbranch ändert.
    • Aktivieren Sie Alle Codereviewerstimmen zurücksetzen, um alle Reviewerstimmen zu entfernen, wenn sich der Quellbranch ändert, einschließlich der Stimmen zum Genehmigen, Ablehnen oder Warten.

Aktivieren des Felds „Code Reviews erforderlich“

  • Wenn Anforderer können ihre eigenen Änderungen genehmigen nicht aktiviert ist, kann der Pull Request-Ersteller immer noch mit Genehmigen für seinen Pull Request abstimmen, aber seine Stimme zählt nicht für die Mindestanzahl von Reviewern.
  • Wenn ein Reviewer die Änderungen ablehnt, kann der Pull Request nicht abgeschlossen werden, es sei denn, Sie aktivieren Fertigstellung zulassen, auch wenn einige Reviewer „Warten“ oder „Ablehnen“ auswählen.
  • Sie können die Stimmen der Reviewer zurücksetzen, wenn neue Änderungen in den Quellbranch gepusht werden. Aktivieren Sie Codereviewerstimmen zurücksetzen, wenn neue Änderungen vorliegen.

Wenn alle anderen Richtlinien erfüllt sind, kann der Ersteller den PR abschließen, wenn die erforderliche Anzahl von Reviewern ihn genehmigt hat.

Auf verknüpfte Arbeitselemente überprüfen

Für die Nachverfolgung der Arbeitselementverwaltung können Sie Zuordnungen zwischen PRs und Arbeitselementen erfordern. Die Verknüpfung von Arbeitselementen bietet mehr Kontext für Änderungen und stellt sicher, dass Aktualisierungen Ihren Prozess zur Nachverfolgung von Arbeitselementen durchlaufen.

Zum Festlegen der Richtlinie legen Sie unter Branchrichtlinien die Option Auf verknüpfte Arbeitselemente überprüfen auf Ein fest. Diese Einstellung setzt voraus, dass Arbeitselemente mit einem PR verknüpft sind, damit der PR zusammengeführt werden kann. Legen Sie die Einstellung als optional fest, um zu warnen, wenn es keine verknüpften Arbeitselemente gibt, aber gestatten Sie das Abschließen des Pull Requests.

Screenshot: Anforderung verknüpfter Arbeitselemente in Pull Requests

Anforderung verknüpfter Arbeitselemente in Ihren Pull Requests

Kommentarauflösung überprüfen

Die Richtlinie Kommentarauflösung überprüfen überprüft, ob alle PR-Kommentare aufgelöst sind.

Konfigurieren Sie eine Richtlinie für die Auflösung von Kommentaren für Ihren Branch, indem Sie Kommentarauflösung überprüfen auf Ein festlegen. Wählen Sie dann aus, ob die Richtlinie erforderlich oder optional sein soll.

Kommentarauflösung überprüfen

Weitere Informationen zur Arbeit mit Pull Request-Kommentaren finden Sie unter Überprüfen von Pull Requests.

Konfigurieren Sie eine Richtlinie für die Auflösung von Kommentaren für Ihren Branch, indem Sie Kommentarauflösung überprüfen aktivieren.

Kommentarauflösung überprüfen

Weitere Informationen zur Arbeit mit Pull Request-Kommentaren finden Sie unter Überprüfen von Pull Requests.

Einschränken von Mergetypen

Azure Repos verfügt über mehrere Mergestrategien, die standardmäßig alle zulässig sind. Sie können einen konsistenten Branchverlauf beibehalten, indem Sie eine Mergestrategie für den PR-Abschluss erzwingen.

Legen Sie Mergetypen einschränken auf Ein fest, um einzuschränken, welche Mergetypen in Ihrem Repository zulässig sind.

Mergetypen einschränken

  • Einfacher Merge (No-Fast-Forward) erstellt einen Mergecommit in dem Ziel, dessen übergeordneten Elemente die Ziel- und Quellbranches sind.
  • Squashmerge erstellt einen linearen Verlauf mit einem einzelnen Commit im Zielbranch mit den Änderungen aus dem Quellbranch. Erfahren Sie mehr über Squashmerges und wie sie sich auf den Branchverlauf auswirken.
  • Rebase und Fast-Forward erstellt einen linearen Verlauf, indem Quellcommits ohne Mergecommit auf dem Zielbranch wiedergegeben werden.
  • Rebase mit Mergecommit gibt die Quellcommits auf dem Ziel wieder und erstellt auch einen Mergecommit.

Hinweis

Dieses Feature ist für Azure DevOps Server 2020 und spätere Versionen verfügbar.

Erzwingen einer Mergestrategie

Behalten Sie einen konsistenten Branchverlauf bei, indem Sie eine Mergestrategie erzwingen, wenn ein Pull Request abgeschlossen ist. Wählen Sie Mergestrategie erzwingen und dann eine Option aus, die erfordert, dass Pull Requests mithilfe dieser Strategie zusammengeführt werden.

Festlegen von Mergeanforderungen

  • No-Fast-Forward-Merge: Diese Option führt den Commitverlauf des Quellbranchs zusammen, wenn der Pull Request geschlossen wird, und erstellt einen Mergecommit im Zielbranch.
  • Squashmerge: Schließen Sie alle Pull Requests mit einem Squashmerge ab, und erstellen Sie einen einzelnen Commit im Zielbranch mit den Änderungen aus dem Quellbranch. Erfahren Sie mehr über Squashmerges und wie sie sich auf Ihren Branchverlauf auswirken.

Buildvalidierung

Sie können eine Richtlinie festlegen, nach der PR-Änderungen erfolgreich erstellt werden müssen, bevor der PR abgeschlossen werden kann. Buildrichtlinien reduzieren Unterbrechungen und sorgen weiterhin dafür, dass Ihre Testergebnisse erfolgreich sind. Buildrichtlinien helfen auch dann, wenn Sie Continuous Integration (CI) in Ihren Entwicklungsbranches verwenden, um Probleme frühzeitig abzufangen.

Eine Richtlinie zur Buildüberprüfung stellt einen neuen Build in die Warteschlange, wenn ein neuer PR erstellt oder Änderungen zu einem vorhandenen PR gepusht werden, der auf den Branch ausgerichtet ist. Die Buildrichtlinie wertet die Buildergebnisse aus, um festzustellen, ob der PR abgeschlossen werden kann.

Wichtig

Bevor Sie eine Richtlinie für die Buildüberprüfung angeben können, müssen Sie über eine Buildpipeline verfügen. Wenn Sie keine Buildpipeline besitzen, finden Sie weitere Informationen unter Erstellen einer Buildpipeline. Wählen Sie den Buildtyp aus, der zu Ihrem Projekttyp passt.

So fügen Sie eine Richtlinie für die Buildüberprüfung hinzu

  1. Wählen Sie die Schaltfläche + neben Buildüberprüfung aus.

    Screenshot: Schaltfläche „Hinzufügen“ neben der Buildüberprüfung

  2. Füllen Sie das Formular Buildrichtlinie festlegen aus:

    Einstellungen für Buildrichtlinie

    • Wählen Sie die Buildpipeline aus.

    • Legen Sie optional einen Pfadfilter fest. Erfahren Sie mehr über Pfadfilter in Branchrichtlinien.

    • Wählen Sie unter Trigger die Option Automatisch (wenn der Quellbranch aktualisiert wird) oder Manuell aus.

    • Wählen Sie unter Richtlinienanforderung die Optionen Erforderlich oder Optional aus. Wenn Sie Erforderlich auswählen, müssen Builds erfolgreich abgeschlossen werden, um PRs abzuschließen. Wählen Sie Optional aus, um eine Benachrichtigung über einen Buildfehler zu erhalten, aber dennoch den Abschluss von PRs zuzulassen.

    • Legen Sie ein Ablaufdatum für den Build fest, um sicherzustellen, dass Updates Ihres geschützten Branchs nicht die Änderungen an offenen PRs unterbrechen.

      • Sofort beim Aktualisieren des <Branchnamens>: Diese Option legt den Status der PR-Buildrichtlinie auf Fehler fest, wenn der Branch aktualisiert wird und stellt einen Build erneut in die Warteschlange. Diese Einstellung stellt sicher, dass die PR-Änderungen erfolgreich erstellt werden, auch wenn der geschützte Branch geändert wird.

        Diese Option eignet sich am besten für Teams, deren wichtige Branches nur wenige Änderungen aufweisen. Teams, die in ausgelasteten Entwicklungsbranches arbeiten, empfinden es möglicherweise als störend, bei jedem Branchupdate auf einen Build zu warten.

      • Nach <n> Stunden, wenn <Branchname> aktualisiert wurde: Mit dieser Option läuft der aktuelle Richtlinienstatus ab, wenn der geschützte Branch aktualisiert wird, wenn der übergebende Build älter ist als der von Ihnen eingegebene Schwellenwert. Diese Option ist ein Kompromiss zwischen den Anforderungen, dass „immer“ und „nie“ ein Build erforderlich ist, wenn der geschützte Branch aktualisiert wird. Diese Option reduziert die Anzahl der Builds, wenn Ihr geschützter Branch häufig aktualisiert wird.

      • Nie: Updates für den geschützten Branch ändern den Status der Richtlinie nicht. Dieser Wert reduziert die Anzahl der Builds, kann aber Probleme verursachen, wenn Sie PRs abschließen, die nicht kürzlich aktualisiert wurden.

    • Geben Sie einen optionalen Anzeigenamen für diese Buildrichtlinie ein. Dieser Name identifiziert die Richtlinie auf der Seite Branchrichtlinien. Wenn Sie keinen Anzeigenamen angeben, verwendet die Richtlinie den Namen der Buildpipeline.

  3. Wählen Sie Speichern aus.

Wenn der PR-Besitzer Änderungen pusht, die erfolgreich erstellt werden, wird der Richtlinienstatus aktualisiert.

Wenn Sie über eine Richtlinie Sofort beim Aktualisieren von <Branchname> oder Nach <n> Stunden, wenn <Branchname> aktualisiert wurde verfügen, wird der Richtlinienstatus aktualisiert, wenn der geschützte Branch aktualisiert wird, sofern der vorherige Branch nicht mehr gültig ist.

Hinweis

Dieses Feature ist für Azure DevOps Server 2020 und spätere Versionen verfügbar.

Legen Sie eine Richtlinie fest, nach der Änderungen in einem Pull Request erfolgreich mit dem geschützten Branch erstellt werden müssen, bevor der Pull Request abgeschlossen werden kann. Buildrichtlinien reduzieren Unterbrechungen und sorgen weiterhin dafür, dass Ihre Testergebnisse erfolgreich sind. Buildrichtlinien helfen auch dann, wenn Sie Continuous Integration (CI) in Ihren Entwicklungsbranches verwenden, um Probleme frühzeitig abzufangen.

Wenn eine Richtlinie zur Buildüberprüfung aktiviert ist, wird ein neuer Build in die Warteschlange gestellt, wenn entweder ein neuer Pull Request erstellt wird oder Änderungen zu einem bestehenden Pull Request gepusht werden, der auf den Branch ausgerichtet ist. Die Buildrichtlinie wertet dann die Ergebnisse des Builds aus, um festzustellen, ob der Pull Request abgeschlossen werden kann.

Wichtig

Bevor Sie eine Richtlinie für die Buildüberprüfung angeben können, müssen Sie über eine Builddefinition verfügen. Wenn Sie keine haben, finden Sie weitere Informationen unter Erstellen einer Builddefinition. Wählen Sie dann den zu Ihrem Projekttyp passenden Buildtyp aus.

Hinzufügen einer Buildrichtlinie

Wählen Sie Buildrichtlinie hinzufügen aus, und konfigurieren Sie Ihre Optionen in Buildrichtlinie hinzufügen.

Einstellungen für Buildrichtlinie

  1. Wählen Sie die Builddefinition aus.

  2. Wählen Sie den Typ für den Trigger aus. Wählen Sie Automatisch (wenn der Quellbranch aktualisiert wird) oder Manuell aus.

  3. Wählen Sie die Richtlinienanforderung aus. Wenn Sie Erforderlich auswählen, müssen Builds erfolgreich abgeschlossen werden, um Pull Requests abzuschließen. Wählen Sie Optional aus, um eine Benachrichtigung über einen Buildfehler zu erhalten, aber dennoch den Abschluss von Pull Requests zuzulassen.

  4. Legen Sie ein Ablaufdatum für den Build fest, um sicherzustellen, dass Updates Ihres geschützten Branchs nicht die Änderungen an offenen Pull Requests unterbrechen.

    • Sofort beim Aktualisieren von branch name: Diese Option legt den Status der Buildrichtlinie in einem Pull Request auf Fehler fest, wenn der geschützte Branch aktualisiert wird. Stellen Sie einen Build erneut in eine Warteschlange, um den Buildstatus zu aktualisieren. Diese Einstellung stellt sicher, dass die Änderungen in Pull Requests erfolgreich erstellt werden, auch wenn der geschützte Branch geändert wird. Diese Option eignet sich am besten für Teams, die wichtige Branches mit einem geringeren Änderungsaufkommen aufweisen. Teams, die in ausgelasteten Entwicklungsbranches arbeiten, empfinden es unter Umständen als störend, bei jedem Update für den geschützten Branch auf die Fertigstellung eines Builds zu warten.
    • Nach n Stunden, wenn branch name aktualisiert wurde: Mit dieser Option läuft der aktuelle Richtlinienstatus ab, wenn der geschützte Branch aktualisiert wird, wenn der übergebende Build älter ist als der von Ihnen eingegebene Schwellenwert. Diese Option ist ein Kompromiss zwischen den Anforderungen, dass „immer“ ein Build erforderlich ist, wenn der geschützte Branch aktualisiert wird, und dass „nie“ einer erforderlich ist. Diese Option eignet sich hervorragend, um die Anzahl der Builds zu reduzieren, wenn Ihr geschützter Branch häufig aktualisiert wird.
    • Nie: Updates für den geschützten Branch ändern den Status der Richtlinie nicht. Dieser Wert reduziert die Anzahl der Builds für Ihren Branch. Es kann zu Problemen führen, wenn Sie Pull Requests schließen, die in letzter Zeit nicht aktualisiert wurden.

  5. Geben Sie einen optionalen Anzeigenamen für diese Buildrichtlinie ein. Dieser Name identifiziert die Richtlinie auf der Seite Branchrichtlinien. Wenn Sie keinen Anzeigenamen angeben, verwendet die Richtlinie den Namen der Builddefinition.

  6. Wählen Sie Speichern aus.

Wenn der Besitzer Änderungen pusht, die erfolgreich erstellt werden, wird der Richtlinienstatus aktualisiert. Wenn Sie die Buildrichtlinie Sofort beim Aktualisieren von branch name oder Nach n Stunden, wenn branch name aktualisiert wurde ausgewählt haben, wird der Richtlinienstatus aktualisiert, wenn der geschützte Branch aktualisiert wird, falls der letzte Branch nicht mehr gültig ist.

Statusüberprüfungen

Externe Dienste können die PR-Status-API verwenden, um detaillierte Status für Ihre PRs zu posten. Die Branchrichtlinie für zusätzliche Dienste ermöglicht es diesen Drittanbieterdiensten, am PR-Workflow teilzunehmen und Richtlinienanforderungen einzurichten.

Erfordern externer Dienste für die Genehmigung

Anweisungen zum Konfigurieren dieser Richtlinie finden Sie unter Konfigurieren einer Branchrichtlinie für einen externen Dienst.

Erfordern einer Genehmigung von externen Diensten

Externe Dienste können die PR-Status-API verwenden, um detaillierte Status für Ihre PRs zu posten. Die Branchrichtlinie für zusätzliche Dienste bietet diesen Drittanbieterdiensten die Möglichkeit, am PR-Workflow teilzunehmen und Richtlinienanforderungen festzulegen.

Erfordern externer Dienste für die Genehmigung

Anweisungen zum Konfigurieren dieser Richtlinie finden Sie unter Konfigurieren einer Branchrichtlinie für einen externen Dienst.

Automatisches Einbeziehen von Codereviewern

Sie können Reviewer automatisch zu Pull Requests hinzufügen, die Dateien in bestimmten Verzeichnissen und Dateien ändern, oder zu allen Pull Requests in einem Repository.

  1. Wählen Sie die Schaltfläche + neben Automatisch einbezogene Reviewer aus.

    Screenshot: Hinzufügen erforderlicher Reviewer

  2. Füllen Sie den Bildschirm Neue Reviewerrichtlinie hinzufügen aus.

    Screenshot: Bildschirm „Neue Reviewerrichtlinie hinzufügen“

    • Fügen Sie Personen und Gruppen zu Reviewer hinzu.

    • Wählen Sie Optional aus, wenn Sie Reviewer automatisch hinzufügen möchten, aber nicht deren Genehmigung zum Abschluss des Pull Requests benötigen.

      Oder wählen Sie Erforderlich aus, wenn Pull Requests nicht abgeschlossen werden können, bis Folgendes zutrifft:

      • Jede Person, die als Reviewer hinzugefügt wird, genehmigt die Änderungen.
      • Mindestens eine Person in jeder Gruppe, die als Reviewer hinzugefügt wurde, genehmigt die Änderungen.
      • Wenn nur eine Gruppe erforderlich ist, genehmigt die von Ihnen angegebene Mindestanzahl von Mitgliedern die Änderungen.

    • Geben Sie die Dateien und Ordner an, für die die automatisch einbezogenen Reviewer benötigt werden. Lassen Sie dieses Feld leer, wenn Sie die Reviewer für alle Pull Requests im Branch benötigen.

    • Wählen Sie Anforderern die Genehmigung eigener Änderungen gestatten aus, wenn Besitzer von Pull Requests über die Genehmigung ihrer eigenen Pull Requests abstimmen können, um diese Richtlinie zu erfüllen.

    • Sie können eine Aktivitätsfeednachricht angeben, die im Pull Request angezeigt wird.

  3. Wählen Sie Speichern aus.

Hinweis

Dieses Feature ist für Azure DevOps Server 2020 und spätere Versionen verfügbar.

Wählen Sie Reviewer für bestimmte Verzeichnisse und Dateien in Ihrem Repository aus.

Eingeben von Pfad und erforderlichen Reviewern

Diese Reviewer werden automatisch zu Pull Requests hinzugefügt, die Dateien entlang dieser Pfade ändern. Sie können auch eine Aktivitätsfeednachricht angeben.

Hinzufügen automatischer Reviewer

Wenn Sie Erforderlich auswählen, kann der Pull Request nicht abgeschlossen werden, bis Folgendes zutrifft:

  • Jeder Benutzer, der als Reviewer für den Pfad hinzugefügt wird, genehmigt die Änderungen.
  • Mindestens eine Person in jeder Gruppe, die dem Pfad hinzugefügt wurde, genehmigt die Änderungen.
  • Die Anzahl der Reviewer, die für jede zum Pfad hinzugefügte Gruppe angegeben ist, genehmigt die Änderungen.

Erforderliche Reviewer werden automatisch hinzugefügt

Wählen Sie Optional aus, wenn Sie Reviewer automatisch hinzufügen möchten, aber nicht deren Genehmigung zum Abschluss des Pull Requests benötigen.

Sie können die Option Anforderer können ihre eigenen Änderungen genehmigen auswählen.

Wenn alle erforderlichen Reviewer den Code genehmigen, können Sie den Pull Request abschließen.

Der Status des Pull Requests zeigt die Genehmigung durch die Reviewer an

Umgehen von Branchrichtlinien

In manchen Fällen müssen Sie die Anforderungen der Richtlinie möglicherweise umgehen. Mithilfe von Umgehungsberechtigungen können Sie Änderungen direkt zu einem Branch pushen oder Pull Requests abschließen, die keine Branchrichtlinien erfüllen. Sie können einem Benutzer oder einer Gruppe Umgehungsberechtigungen erteilen. Sie können die Umgehungsberechtigungen auf ein ganzes Projekt, ein Repository oder einen einzelnen Branch anwenden.

Zwei Berechtigungen ermöglichen es Benutzern, die Branchrichtlinien auf unterschiedliche Weise zu umgehen:

  • Richtlinien beim Abschließen von Pull Requests umgehen gilt nur für den Abschluss von Pull Requests. Benutzer mit dieser Berechtigung können Pull Requests abschließen, auch wenn die Anforderungen nicht die Richtlinien erfüllen.

  • Richtlinien bei Pushvorgängen umgehen gilt für Pushvorgänge aus lokalen Repositorys und für Bearbeitungen, die im Web vorgenommen wurden. Benutzer mit dieser Berechtigung können Änderungen direkt zu geschützten Branches pushen, ohne die Richtlinienanforderungen zu erfüllen.

Screenshot: Berechtigungen zum Umgehen der Richtlinienerzwingung

Weitere Informationen zur Verwaltung dieser Berechtigungen finden Sie unter Git-Berechtigungen.

In TFS 2015 bis TFS 2018 Update 2 können Benutzer mit der Berechtigung Ausgenommen von Richtlinienerzwingung die folgenden Aktionen durchführen:

  • Wenn Sie einen Pull Request abschließen, können Sie sich dafür entscheiden, Richtlinien außer Kraft zu setzen und einen Pull Request abzuschließen, selbst wenn die aktuelle Gruppe der Branchrichtlinien nicht erfüllt ist.
  • Pushen Sie direkt in einen Branch, auch wenn für diesen Branch Branchrichtlinien festgelegt sind. Beachten Sie, dass wenn ein Benutzer mit dieser Berechtigung einen Push durchführt, der die Branchrichtlinie außer Kraft setzt, umgeht der Push die Branchrichtlinie automatisch ohne Zustimmungsschritt oder Warnung.

Wichtig

Seien Sie bei der Gewährung der Möglichkeit zum Umgehen von Richtlinien umsichtig, insbesondere auf der Repository- und Projektebene. Richtlinien sind der Grundstein für eine sichere und konforme Quellcodeverwaltung.

Pfadfilter

Verschiedene Branchrichtlinien bieten Pfadfilter. Wenn ein Pfadfilter festgelegt ist, gilt die Richtlinie nur für Dateien, die dem Pfadfilter entsprechen. Wenn Sie dieses Feld leer lassen, bedeutet dies, dass die Richtlinie für alle Dateien im Branch gilt.

Sie können absolute Pfade (der Pfad muss entweder mit / oder einem Platzhalter beginnen) und Platzhalter angeben. Beispiele:

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

Sie können mehrere Pfade angeben, indem Sie ; als Trennzeichen verwenden. Beispiel:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

Pfade mit dem Präfix ! werden ausgeschlossen, wenn sie sonst enthalten wären. Beispiel:

  • /WebApp/*;!/WebApp/Tests/* enthält alle Dateien in /WebApp mit Ausnahme der Dateien in /WebApp/Tests
  • !/WebApp/Tests/* gibt keine Dateien an, da zunächst nichts einbezogen wird

Die Reihenfolge der Filter ist wichtig. Filter werden von links nach rechts angewendet.

Fragen und Antworten

Kann ich Änderungen direkt in Branches pushen, die über Branchrichtlinien verfügen?

Sie können Änderungen nicht direkt in Branches pushen, die erforderliche Branchrichtlinien aufweisen, es sei denn, Sie verfügen über die Berechtigung Branchrichtlinien umgehen. Änderungen an diesen Branches können nur über Pull Requests vorgenommen werden. Sie können Änderungen direkt in Branches mit optionalen Branchrichtlinien pushen, wenn diese keine erforderlichen Branchrichtlinien aufweisen.

Was ist die automatische Vervollständigung?

Pull Requests in Branches, für die Richtlinien festgelegt wurden, verfügen über die Schaltfläche Automatische Vervollständigung festlegen. Wählen Sie diese Option aus, um den Pull Request automatisch abzuschließen, sobald er alle Richtlinien erfüllt. Die automatische Vervollständigung ist nützlich, wenn Sie keine Probleme mit Ihren Änderungen erwarten.

Wann werden die Bedingungen der Branchrichtlinien geprüft?

Branchrichtlinien werden auf dem Server neu ausgewertet, wenn Besitzer von Pull Requests Änderungen pushen und wenn Reviewer abstimmen. Wenn eine Richtlinie einen Build auslöst, wird der Buildstatus auf „Warten“ festgelegt, bis der Build abgeschlossen ist.

Kann ich XAML-Builddefinitionen in Branchrichtlinien verwenden?

Nein, Sie können keine XAML-Builddefinitionen in Branchrichtlinien verwenden.

Welche Platzhalterzeichen kann ich für erforderliche Codereviewer verwenden?

Einzelne Sternchen * entsprechen einer beliebigen Anzahl von Zeichen, einschließlich Schrägstrichen / und umgekehrten Schrägstrichen \. Fragezeichen ? vergleichen jedes einzelne Zeichen.

Beispiele:

  • *.sql entspricht allen Dateien mit der SQL-Erweiterung.
  • /ConsoleApplication/* entspricht allen Dateien unter dem Ordner ConsoleApplication.
  • /.gitattributes entspricht der Datei .gitattributes im Stammverzeichnis des Repository.
  • */.gitignore entspricht jeder .gitignore-Datei im Repository.

Wird bei den Codereviewerpfaden die Groß-/Kleinschreibung beachtet?

Nein, Branchrichtlinien beachten nicht die Groß-/Kleinschreibung.

Wie kann ich mehrere Benutzer als erforderliche Reviewer konfigurieren, aber nur einen von ihnen zur Genehmigung erfordern?

Sie können die Benutzer zu einer Gruppe hinzufügen, und dann die Gruppe als Reviewer hinzufügen. Jedes Mitglied der Gruppe kann dann genehmigen, um die Richtlinienanforderung zu erfüllen.

Ich verfüge über Berechtigungen zur Umgehung der Richtlinie. Warum werden immer noch Richtlinienfehler im Pull Request-Status angezeigt?

Konfigurierte Richtlinien werden bei Änderungen an Pull Requests immer ausgewertet. Für Benutzer, die über Berechtigungen zur Umgehung der Richtlinie verfügen, ist der gemeldete Status der Richtlinie nur „beratend“. Wenn der Benutzer mit Umgehungsberechtigungen zustimmt, blockiert der Fehlerstatus nicht den Abschluss des Pull Requests.

Warum kann ich meine eigenen Pull Requests nicht abschließen, wenn „Anforderern die Genehmigung eigener Änderungen gestatten“ festgelegt ist?

Sowohl die Richtlinie Mindestanzahl von Reviewern erfordern als auch die Richtlinie Automatisch einbezogene Reviewer verfügt über die Option Anforderern die Genehmigung eigener Änderungen gestatten. In jeder Richtlinie gilt die Einstellung nur für diese Richtlinie. Die Einstellung hat keinen Einfluss auf die anderen Richtlinien.

In Ihrem Pull Request sind z. B. die folgenden Richtlinien festgelegt:

  • Mindestanzahl von Reviewern erfordern erfordert mindestens einen Reviewer.
  • Automatisch einbezogene Reviewer erfordert Sie oder ein Team, in dem Sie sich befinden, als Reviewer.
  • Automatisch einbezogene Reviewer hat Anforderern die Genehmigung eigener Änderungen gestatten aktiviert.
  • Mindestanzahl von Reviewern erfordern hat Anforderern die Genehmigung eigener Änderungen gestatten nicht aktiviert.

In diesem Fall erfüllt Ihre Genehmigung Automatisch einbezogene Reviewer, aber nicht Mindestanzahl von Reviewern erfordern, sodass Sie den Pull Request nicht abschließen können.

Es kann auch andere Richtlinien geben, z. B. Letzte Push ausführende Person daran hindern, eigene Änderungen zu genehmigen, die Sie daran hindern, Ihre eigenen Änderungen zu genehmigen, selbst wenn Anforderern die Genehmigung eigener Änderungen gestatten festgelegt ist.

Was passiert, wenn der Pfad in Pfadfiltern weder mit / noch mit einem Platzhalter beginnt?

Der Pfad in Pfadfiltern, die weder mit / noch mit einem Platzhalter beginnen, hat keine Auswirkung und der Pfadfilter wird so ausgewertet, als ob dieser Pfad nicht angegeben wäre. Das liegt daran, dass ein solcher Pfad nicht mit dem / übereinstimmen kann, mit dem der absolute Dateipfad beginnt.