Informationen zu Pull Requests

  • Artikel

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

Mit Pull Requests (PRs) können Sie Code in einem Git-Repository in Azure Repos ändern, überprüfen und zusammenführen. PRs können aus Branches innerhalb desselben Repositorys oder aus Branches in Forks des Repositorys stammen. Teams verwenden PRs, um Code zu überprüfen und Feedback zu Änderungen zu geben, bevor der Code in den Hauptbranch zusammengeführt wird. Reviewer können sich die vorgeschlagenen Änderungen Schritt für Schritt ansehen, Kommentare hinterlassen und den Code genehmigen oder ablehnen.

In diesem Artikel werden die Pull Request-Richtlinien und die Aspekte der Verwaltung beschrieben. Anweisungen zum Erstellen, Anzeigen, Überprüfen und Abschließen von Pull Requests finden Sie in den folgenden Artikeln:

Hinweis

Aus Leistungs- und Stabilitätsgründen muss die Anzahl der Prüfer, die einem Pull Request hinzugefügt werden können, 1.000 oder weniger sein. Neue Pull Requests werden nicht erstellt, wenn mehr als 1.000 Prüfer hinzugefügt werden. Bei vorhandenen Pull Requests Sie nicht mehr als 1.000 Prüfer hinzuzufügen.

Berechtigungen und Voraussetzungen

  • Repos muss in Ihrem Projekt aktiviert sein. Wenn der Repos-Hub und die zugehörigen Seiten nicht angezeigt werden, lesen Sie Aktivieren oder Deaktivieren eines Azure DevOps-Diensts, um Repos neu zu aktivieren.

  • Um PRs anzuzeigen oder zu überprüfen, müssen Sie Mitglied eines Azure DevOps-Projekts mit Zugriff der Ebene Basic oder höher sein.

  • Um zu einem PR beizutragen, müssen Sie Mitglied der Sicherheitsgruppe Leser sein oder über die entsprechenden Berechtigungen verfügen.

  • Um einen PR zu erstellen und abzuschließen, müssen Sie Mitglied der Sicherheitsgruppe Mitwirkende sein oder über die entsprechenden Berechtigungen verfügen.

Hinweis

Bei öffentlichen Projekten haben Benutzer, denen Beteiligtenzugriff eingeräumt wurde, vollen Zugriff auf Azure Repos.

  • Repos muss in Ihrem Projekt aktiviert sein. Wenn der Repos-Hub und die zugehörigen Seiten nicht angezeigt werden, lesen Sie Aktivieren oder Deaktivieren eines Azure DevOps-Diensts, um Repos neu zu aktivieren.
  • Um PRs anzuzeigen oder zu überprüfen, müssen Sie Mitglied eines Azure DevOps-Projekts mit Zugriff der Ebene Basic oder höher sein. Wenn Sie kein Projektmitglied sind, lassen Sie sich hinzufügen.
  • Um zu einem PR beizutragen, müssen Sie Mitglied der Sicherheitsgruppe Leser sein oder über die entsprechenden Berechtigungen verfügen.
  • Um einen PR zu erstellen und abzuschließen, müssen Sie Mitglied der Sicherheitsgruppe Mitwirkende sein oder über die entsprechenden Berechtigungen verfügen.

Weitere Informationen zu Berechtigungen und Zugriff finden Sie unter Standardmäßige Git-Repository- und Branchberechtigungen und Informationen zu Zugriffsebenen.

Qualitätsfeedback für Pull Requests

Qualitativ hochwertige Reviews beginnen mit qualitativ hochwertigem Feedback. Hier sind einige Schlüssel zum Erstellen von PR-Feedback:

  • Der PR-Besitzer sollte die richtigen Personen den PR überprüfen lassen und sicherstellen, dass die Reviewer wissen, was der Code tut.
  • Reviewer sollten umsetzbares, konstruktives Feedback geben.
  • Besitzer und Reviewer sollten schnell kommentieren und antworten.

PR-Besitzer sollten wie folgt vorgehen:

  • Stellen Sie sicher, dass Sie die richtigen Reviewer auswählen, die einem PR zugewiesen werden sollen.
  • Beziehen Sie Reviewer ein, die wissen, wie der Code funktioniert.
  • Bitten Sie Entwickler, die in anderen Bereichen arbeiten, ihre Ideen zu teilen.
  • Geben Sie eine klare Beschreibung der Änderungen ab.
  • Stellen Sie eine Anleitung für Reviewer mit Pull Request-Vorlagen bereit.
  • Stellen Sie einen Build des Codes mit dem Fix oder dem Feature bereit, die darin ausgeführt werden.
  • Antworten Sie auf Kommentare, akzeptieren Sie Vorschläge oder erklären Sie, warum die vorgeschlagene Änderung nicht ideal ist.
  • Erstellen Sie für gute Vorschläge außerhalb des Pr-Bereichs neue Arbeitselemente, Branches und PRs, um diese Änderungen vorzunehmen.

Prüfer sollten folgende Aufgaben ausführen.

  • Geben Sie Feedback zu Änderungen, mit denen Sie nicht einverstanden sind
  • Identifizieren Sie Probleme und geben Sie konkrete Vorschläge, was anders zu machen ist
  • Stellen Sie sicher, dass das Feedback eine klare Absicht erkennen lässt und leicht zu verstehen ist
  • Kommentare hinterlassen oder über Änderungen abstimmen

Weitere Informationen finden Sie unter Abrufen von Feedback mit Git-Pull Requests.

Branchrichtlinien und Pull Requests

Ihr Team kann sich darauf verlassen, dass wichtige Branches in Ihrem Repository, z. B. der main-Branch, immer in guter Verfassung sind. Sie können Branchrichtlinien so festlegen, dass PRs für alle Änderungen in diesen geschützten Branches erforderlich sind, und alle Änderungen ablehnen, die direkt an die Branches gepusht werden.

Sie können PRs weitere Richtlinien hinzufügen, um eine bessere Codequalität in Schlüsselbranchen zu durchzusetzen. Zusätzliche Anforderungen wie ein sauberer Build des vorgeschlagenen Codes oder die Genehmigung mehrerer Reviewer können dazu beitragen, Schlüsselbranches zu schützen.

Sie können die Anzahl der erforderlichen Genehmigungen für einen PR in einer Branchrichtlinie festlegen. Sie können auch festlegen, dass bestimmte Reviewer für alle oder bestimmte PRs erforderlich sind oder herangezogen werden können. Ein PR kann mit der erforderlichen Anzahl von Genehmigungen auf „Autovervollständigen“ festgelegt werden, auch wenn andere Reviewer die Änderungen ablehnen. Erforderliche Reviewer müssen PRs jedoch genehmigen, bevor die PRs zusammengeführt werden können. Es empfiehlt sich, dass mindestens zwei Reviewer Änderungen in einem wichtigen PR überprüfen und genehmigen.

Um Abstimmungen zurückzusetzen, wenn ein PR-Ersteller neue Änderungen pusht, wählen Sie Codereviewerstimmen zurücksetzen, wenn neue Änderungen vorliegen in der Branchrichtlinie Mindestanzahl von Reviewern erforderlich aus.

In der folgenden Tabelle sind die Richtlinien zusammengefasst, die Sie zum Anpassen eines Branchs definieren können. Eine Übersicht über alle Repository- und Branchrichtlinien und -einstellungen finden Sie unter Festlegen von Git-Repositoryeinstellungen und -Richtlinien.

Richtlinie

Standard

Beschreibung

Mindestanzahl von Reviewern erforderlich

Aus

Genehmigung von einer bestimmten Anzahl von Reviewern für Pull Requests erfordern.

Auf verknüpfte Arbeitselemente überprüfen

Aus

Nachverfolgbarkeit fördern, indem nach verknüpften Arbeitselementen in Pull Requests gesucht wird

Kommentarauflösung überprüfen

Aus

Überprüfen, ob alle Kommentare zu Pull Requests aufgelöst wurden.

Mergetypen einschränken

Aus

Den Branchverlauf steuern, indem die verfügbaren Mergetypen beim Abschließen von Pull Requests begrenzt werden.

Hinzufügen von Buildvalidierungsrichtlinien

Aus

Eine oder mehrere Richtlinien hinzufügen, um Code durch Vorabzusammenführen und Erstellen von Pull Request-Änderungen zu überprüfen. Kann auch Richtlinien aktivieren oder deaktivieren.

Hinzufügen von Statusüberprüfungsrichtlinien

Aus

Eine oder mehrere Richtlinien hinzufügen, damit andere Dienste erfolgreiche Status veröffentlichen, um Pull Requests abzuschließen. Kann auch Richtlinien aktivieren oder deaktivieren.

Automatisch einbezogene Reviewer

Aus

Eine oder mehrere Richtlinien hinzufügen, um Codeprüfer festzulegen, die automatisch einbezogen werden sollen, wenn Pull Requests bestimmte Codebereiche ändern. Kann auch Richtlinien aktivieren oder deaktivieren.

Weitere Informationen finden Sie unter:

Definieren von Statusprüfungen zur Verbesserung der Codequalität

Pull Requests und Branchrichtlinien ermöglichen es Teams, bewährte Methoden für die Überprüfung von Code und die Ausführung automatisierter Builds zu durchzusetzen. Viele Teams müssen weitere Anforderungen und Überprüfungen für Code durchführen. Um diese Anforderungen zu erfüllen, können Sie PR-Statusüberprüfungen in den PR-Workflow integrieren. Mit PR-Statusüberprüfungen können externe Dienste Codeänderungen programmgesteuert abmelden, indem sie dem PR Erfolgs- oder Fehlerinformationen zuordnen.

Weitere Informationen finden Sie in den folgenden Artikeln:

Problem mit mehreren Mergebasen

In einigen Fällen hat ein PR mehr als eine wahre Mergebasis, und diese Situation kann zu Sicherheitsproblemen führen. Wenn die Dateien im PR unterschiedliche Versionen zwischen den Zusammenführungsbasen aufweisen, wird eine Warnung über mehrere Zusammenführungsbasen ausgegeben. Weitere Informationen und Abhilfemaßnahmen finden Sie unter Mehrere Mergebasen.

Nächste Schritte