Branchrichtlinien festlegen und verwalten

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

Verwenden Sie Branchrichtlinien, um wichtige Branches zu schützen, indem Pull Requests, Reviewer, Builds und andere Überprüfungen erforderlich sind, bevor Änderungen zusammengeführt werden. In diesem Artikel wird erläutert, wie Sie Verzweigungsrichtlinien im Azure DevOps Webportal und Azure DevOps CLI konfigurieren und verwalten. Eine Zusammenfassung der verfügbaren Verzweigungsrichtlinien und Anleitungen zur Verzweigung finden Sie unter Informationen zu Verzweigungen und Verzweigungsrichtlinien.

Einen umfassenden Sicherheitsleitfaden zu Branchrichtlinien, Zugriffssteuerung für Repositorys, Commitsignierung und praxisnahen Implementierungsszenarien finden Sie unter Sichere Repositorys und Pull Requests.

Sie können keinen Branch löschen, für den erforderliche Richtlinien konfiguriert sind, und alle Änderungen müssen über Pull Requests (PRs) erfolgen.

Tipp

Sie können KI verwenden, um Ihnen bei dieser Aufgabe zu helfen später in diesem Artikel oder sehen Sie sich an, wie Sie die KI-Unterstützung bei Azure DevOps MCP Server aktivieren, um loszulegen.

Voraussetzungen

Anforderung Details
Permissions Mitglied der Sicherheitsgruppe "Project Administrators" sein oder über die Berechtigung auf Repositoryebene "Richtlinien bearbeiten" verfügen. Weitere Informationen finden Sie unter Festlegen von Git-Repositoryberechtigungen.
Azure DevOps CLI-Setup (optional) Um Azure DevOps CLI az repos-Richtlinienbefehle zu verwenden, führen Sie "Erste Schritte mit Azure DevOps CLI" aus.
Ziel-Repository für CLI festlegen (optional) Bevor Sie Richtlinien in CLI erstellen oder aktualisieren, identifizieren Sie die Repository-ID, indem Sie ausführen az repos list. Um --org und --project nicht zu wiederholen, legen Sie Standardwerte mit az devops configure --defaults fest.
Richtlinienabhängigkeiten Bevor Sie die Buildüberprüfung konfigurieren, können Sie eine Buildpipeline erstellen. Bevor Sie Statusüberprüfungen konfigurieren, stellen Sie sicher, dass der externe Dienst oder die integrierte Integration den Status der Pullanforderung bereits bereitstellen kann.
Einrichtung von KI-Unterstützung (optional) Um KI-Unterstützung bei Azure DevOps MCP-Server zu verwenden, verwenden Sie Azure DevOps Services, aktivieren Sie den Agentmodus in Ihrem KI-Assistenten, und installieren Sie Node.js 20.0+. Weitere Informationen finden Sie unter Aktivieren der KI-Unterstützung bei Azure DevOps MCP-Server.
Anforderung Details
Permissions Mitglied der Sicherheitsgruppe „Project-Administratoren“ sein oder über Berechtigungen auf Repository-Ebene „Richtlinien bearbeiten“ verfügen. Weitere Informationen finden Sie unter Festlegen von Git-Repositoryberechtigungen.

Öffnen von Branch-Richtlinieneinstellungen

So öffnen Sie Branch-Richtlinieneinstellungen im Webportal:

  1. Wählen Sie Repository>Verzweigungen aus.
  2. Suchen Sie den Branch, den Sie verwalten möchten.
  3. Wählen Sie neben dem Branch das Symbol „Weitere Optionen“ aus, und wählen Sie dann „Branchrichtlinien“ aus.

Screenshot: Menüelement „Branches“

Sie können die Einstellungen für Branchrichtlinien auch unter Projekteinstellungen>Repository>Richtlinien>Branchrichtlinien><Branchname> öffnen.

Branches, für die Richtlinien gelten, zeigen ein Richtliniensymbol an. Wählen Sie das Symbol aus, um direkt zu den Richtlinieneinstellungen des Branches zu gelangen.

Sie können die Liste durchsuchen oder im Feld Branch-Namen suchen nach dem Branch suchen.

Screenshot: Öffnen der Branchrichtlinien über das Kontextmenü

Konfigurieren Sie die Richtlinien auf der Einstellungsseite des Branches. Verwenden Sie die folgenden Abschnitte, um jede Richtlinie zu aktivieren oder eine vorhandene Richtlinie zu aktualisieren.

Festlegen einer Mindestüberprüfungsrichtlinie

Erfordert die Genehmigung durch eine Mindestanzahl von Prüfern, bevor ein Pull Request abgeschlossen werden kann.

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, das die Richtlinie „Erforderliche Codeüberprüfungen aktivieren“ zeigt.

  • Wählen Sie Anforderern die Genehmigung eigener Änderungen gestatten aus, damit der PR-Ersteller über dessen Genehmigung abstimmen kann. Andernfalls kann der Ersteller den PR zwar weiterhin mit Approve genehmigen, seine Stimme wird jedoch nicht auf die Mindestanzahl an Prüfern angerechnet.

  • 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 normalerweise ihre eigenen Änderungen 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 jede Iteration erforderlich, um mindestens eine Genehmigungsstimme für die letzte Änderung am Quellbranch zu erfordern. Die Genehmigungen der Benutzer*innen werden nicht auf vorherige nicht genehmigte Iterationen angerechnet, die von diesen Benutzer*innen gepusht wurden. Daher ist eine weitere Genehmigung für die letzte Iteration durch eine(n) andere(n) Benutzer*in erforderlich. Mindestens eine Genehmigung für jede Iteration anfordern ist in Azure DevOps Server 2022.1 und höher 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.

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

Verknüpfte Arbeitsaufgaben erforderlich

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

Auflösung des Kommentars erforderlich

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

Legen Sie Auf Kommentarauflösung prüfen auf Ein fest, um eine Kommentarauflösungsrichtlinie für Ihren Branch zu konfigurieren. Wählen Sie dann aus, ob die Richtlinie erforderlich oder optional sein soll.

Screenshot für „Kommentarauflösung prüfen“.

Weitere Informationen zum Arbeiten mit Pullanforderungskommentaren finden Sie unter Überprüfen von Pullanforderungen.

Einschränken von Mergetypen

Azure Repos unterstützt mehrere Zusammenführungsstrategien und ermöglicht standardmäßig alle. Um einen konsistenten Verzweigungsverlauf beizubehalten, erzwingen Sie eine Zusammenführungsstrategie für den PR-Abschluss.

Setzen Sie Zusammenführungstypen einschränken auf Aktiviert, um die in Ihrem Repository zulässigen Zusammenführungstypen einzuschränken.

Screenshot für „Mergetypen einschränken“.

  • Basic merge (no fast-forward) erzeugt einen Merge-Commit im Ziel, dessen übergeordnete Elemente die Ziel- und Quellzweige sind.
  • Squash-Merge erstellt einen linearen Verlauf mit einem einzelnen Commit im Ziel-Branch, der die Änderungen aus dem Quell-Branch enthält. Erfahren Sie mehr über Squash-Merging und wie es sich auf die Branch-Historie auswirkt.
  • Wiederholen und vorspulen erzeugt eine lineare Historie, indem es die Quell-Commits auf dem Zielzweig ohne Merge-Commit wiedergibt.
  • Rebase mit Merge-Commit überträgt die Quell-Commits auf das Ziel und erstellt außerdem einen Merge-Commit.

Festlegen der Buildüberprüfung

Legen Sie eine Richtlinie fest, die erfordert, dass PR-Änderungen erfolgreich erstellt werden, bevor die PR abgeschlossen werden kann. Buildrichtlinien reduzieren Unterbrechungen und sorgen weiterhin dafür, dass Ihre Testergebnisse erfolgreich sind. Build-Strategien helfen auch dann, wenn Sie Continuous Integration (CI) in Ihren Entwicklungszweigen verwenden, um Probleme frühzeitig zu erkennen.

Wenn Sie den Richtlinienauslöser auf Automatisch festlegen, stellt eine Buildvalidierungsrichtlinie einen neuen Build in die Warteschlange, wenn Sie eine neue PR erstellen oder Änderungen per Push an eine vorhandene PR übermitteln, die auf den Branch abzielt. Wenn Sie den Richtlinientrigger auf "Manuell" festlegen, müssen Benutzer den Build selbst in die Warteschlange stellen. In beiden Fällen wertet die Richtlinie die Ergebnisse des Builds aus, um zu bestimmen, ob der PR abgeschlossen werden darf.

Wichtig

Bevor Sie eine Richtlinie zur Buildüberprüfung angeben, erstellen Sie eine Buildpipeline. 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-Validierung aus.

    Screenshot, der die Schaltfläche „Hinzufügen“ neben der Build-Validierung zeigt

  2. Füllen Sie das Formular Build-Policy festlegen aus:

    Screenshot der Einstellungen für Build-Richtlinien.

    • Wählen Sie die Build-Pipeline 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, wenn der <Branch-Name> aktualisiert wird: Diese Option setzt den PR-Build-Policy-Status auf failed, wenn der Branch aktualisiert wird, und fordert einen Build an. 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 warten zu müssen.

    • Nach <n> Stunden, wenn der <Branch-Name> aktualisiert wurde: Mit dieser Option läuft der aktuelle Richtlinienstatus ab, wenn der geschützte Zweig aktualisiert wird und der übergebene 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 jedoch Probleme verursachen, wenn PRs abgeschlossen werden, 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.

  1. 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.

Statusprüfungen erforderlich machen

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 diesen externen Diensten die Teilnahme am PR-Workflow und die Festlegung von Richtlinienanforderungen.

Screenshot von „Externe Dienste zur Genehmigung erforderlich“.

So konfigurieren Sie eine Statusüberprüfungsrichtlinie:

  1. Stellen Sie sicher, dass der Dienst den Pullanforderungsstatus an Azure Repos senden kann.
  2. Wählen Sie in Branchrichtlinien unter Statusüberprüfungen die Option + aus.
  3. Wählen Sie in Status zur Prüfung die gebuchte Prüfung aus der Liste aus. Wenn der Dienst noch keinen Status angezeigt hat, geben Sie den genre/name-Wert direkt ein.
  4. Legen Sie die Richtlinienanforderung auf "Erforderlich " oder "Optional" fest.
  5. Konfigurieren Sie optional Autorisierte Identität, Zurücksetzungsbedingungen, Richtlinienanwendbarkeit und Pfadfilter.
    • Verwenden Sie Standardmäßig anwenden, wenn die Richtlinie angewendet werden soll, sobald der Pull Request erstellt wird.
    • Verwenden Sie "Bedingt ", wenn die Richtlinie erst angewendet werden soll, nachdem der erste Status gepostet wurde.
  6. Erstellen oder aktualisieren Sie einen Pull Request, der auf den Branch abzielt, und bestätigen Sie, dass die Richtlinie im Abschnitt Policies des PRs angezeigt wird.

Informationen zu integrierten Azure DevOps Services-Überprüfungen und deren genre/name Bezeichnern finden Sie unter "Verfügbare Pullanforderungsstatusüberprüfungen". Eine ausführliche Schritt-für-Schritt-Anleitung zum Einrichten externer Dienste finden Sie in Konfigurieren einer Verzweigungsrichtlinie für einen externen Dienst.

Wenn eine neue Integration noch nicht in der Dropdownliste angezeigt wird, posten Sie den Status einmal aus dem Dienst, und fügen Sie dann die Richtlinie hinzu, oder geben Sie den genre/name Wert direkt ein.

Reviewer automatisch einschließen

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, das das Hinzufügen von erforderlichen Reviewern zeigt

  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.

Richtlinienumgehung bei Bedarf zulassen

In manchen Fällen müssen Sie die Anforderungen der Richtlinie möglicherweise umgehen. Mithilfe von Bypass-Berechtigungen können Sie Änderungen direkt zu einem Branch pushen oder Pull Requests abschließen, die keine Branch-Richtlinien erfüllen. Sie können einem Benutzer oder einer Gruppe Umgehungsberechtigungen erteilen und diese Berechtigungen auf ein gesamtes Projekt, ein Repository oder eine einzelne Verzweigung beschränken.

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 das Abschließen von Pull Requests. Benutzer mit dieser Berechtigung können Pull Requests abschließen, selbst wenn die Pull Requests die Richtlinien nicht erfüllen.

  • Richtlinien beim Pushen umgehen gilt für Pushes aus lokalen Repositories und Bearbeitungen im Web. 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.

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 mit Verzweigungsrichtlinien verwenden

Mehrere Branchrichtlinien unterstützen Pfadfilter. Wenn Sie einen Pfadfilter festlegen, gilt die Richtlinie nur für Dateien, die dem Filter entsprechen. Lassen Sie dieses Feld leer, um die Richtlinie auf alle Dateien im Branch anzuwenden.

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

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

Sie können mehrere Pfade mithilfe ; eines Trennzeichens angeben. Beispiel:

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

Wenn Sie Pfade !voranstellen, schließen Sie sie aus, wenn sie andernfalls enthalten sind. 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. Anwenden von Filtern von links nach rechts.

Beheben von Problemen mit Verzweigungsrichtlinien

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

Sie können Änderungen nicht direkt zu Branches pushen, die Branchrichtlinien erfordern, es sei denn, Sie verfügen über die Berechtigung für die Umgehung von Branchrichtlinien. Sie können nur Änderungen an diesen Verzweigungen über Pullanforderungen vornehmen. Sie können Änderungen direkt in Branches mit optionalen Branchrichtlinien pushen, wenn diese keine erforderlichen Branchrichtlinien aufweisen.

Was ist die automatische Vervollständigung?

Branches mit für Pull Requests konfigurierten Branchrichtlinien haben die Schaltfläche "Automatisches Abschließen festlegen". Aktivieren Sie diese Option, um eine Pullanforderung auf autoVervollständigen festzulegen , sobald alle Richtlinien erfüllt sind. Die automatische Vervollständigung ist nützlich, wenn Sie keine Probleme mit Ihren Änderungen erwarten.

Wann werden die Bedingungen der Branchrichtlinien geprüft?

Der Server wertet Verzweigungsrichtlinien erneut aus, wenn die Besitzer von Pull Requests Änderungen pushen und wenn die Prüfer 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 ? ersetzen 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 sind nicht case-sensitive.

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?

Das System wertet immer konfigurierte Richtlinien für Pullanforderungsänderungen aus. Für Benutzer mit Berechtigungen zum Umgehen von Richtlinien ist der gemeldete Richtlinienstatus nur informativ. 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 ich „Antragstellern erlauben, ihre eigenen Änderungen zu genehmigen“ festgelegt habe?

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 aufgenommene Rezensenten erfordert Sie oder ein Team, in dem Sie als Rezensent sind.
  • Automatisch enthaltene Überprüfer hat Antragsteller zulassen, ihre eigenen Änderungen zu genehmigen 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.

Andere Richtlinien verhindern möglicherweise, dass Sie Ihre eigenen Änderungen genehmigen, auch wenn Die Anforderer ihre eigenen Änderungen genehmigen können. Verbieten Sie beispielsweise, dass die Person, die den letzten Push ausgeführt hat, ihre eigenen Änderungen genehmigt.

Was geschieht, wenn ein Pfadfilter nicht mit / oder einem Wildcardfilter beginnt?

Ein Pfad in Pfadfiltern, die nicht mit / oder mit einem Wildcard beginnen, hat keine Auswirkung. Der Pfadfilter wertet aus, als ob dieser Pfad nicht angegeben wurde. Ein solcher Pfad kann nicht mit dem / übereinstimmen, mit dem der absolute Dateipfad beginnt.

Verwenden von KI zum Konfigurieren und Verwalten von Zweigstellenrichtlinien

Wenn Sie den Azure DevOps MCP-Server konfigurieren, können Sie mithilfe natürlicher Sprache vor dem Aktualisieren von Branchrichtlinien in Azure DevOps Services Informationen zu Repositorys, Branches, Pull Requests und Builds abrufen.

Der Azure DevOps MCP-Server erfordert Azure DevOps Dienste, den Agentmodus in Ihrem KI-Assistenten und Node.js 20,0+. Die aktuelle MCP-Dokumentation beschreibt keine Lese- oder Schreibaktionen für Direct Branch-Richtlinien. Verwenden Sie daher das Azure DevOps Webportal oder Azure DevOps CLI, um Richtlinien zu erstellen und zu aktualisieren.

Aufgabe Beispielaufforderung
Verzweigungen in einem Repository auflisten List the branches in repo <Contoso.Web> in project <Contoso>
Pull Requests überprüfen, bevor die Richtlinie verschärft wird What pull requests require my review in project <Contoso>?
Überprüfen einer Pullanforderung und verknüpfter Arbeitsaufgaben Get details for pull request <67> and its linked work items in project <Contoso>
Buildstatus überprüfen, bevor die Buildüberprüfung erforderlich gemacht wird Get the latest build status for pipeline <Contoso-CI> in project <Contoso>

Note

Wenn Sie Visual Studio Code verwenden, ist der Agentmodus besonders hilfreich, um den benötigten Projektkontext zu erfassen, bevor Sie Verzweigungsrichtlinien aktualisieren.

Verwandte Inhalte

  • Last updated on