Freigeben über

Informationen zu Branches und Branchrichtlinien

  • Artikel

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

Branchrichtlinien bilden einen wichtigen Teil des Git-Workflows und bieten folgende Möglichkeiten:

  • Isolieren von laufender Arbeit von der abgeschlossenen Arbeit in Ihrem Mainbranch
  • Sicherstellen, dass Änderungen kompiliert werden, bevor sie in Main übernommen werden
  • Einschränken, wer an bestimmten Branches mitwirken kann
  • Durchsetzen, wer Branches erstellen kann, und Erzwingen der Benennungsrichtlinien für die Branches
  • Automatisches Einbeziehen der richtigen Prüfer für jede Codeänderung
  • Erzwingen von bewährten Methoden für die erforderlichen Codeprüfer

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.

Übernehmen einer Git-Verzweigungsstrategie

Es gibt einige wichtige Branches in Ihrem Repository, bei denen sich das Team immer auf die ordnungsgemäße Form verlassen können muss (z. B. main-Branch).

Sehen Sie vor, dass für Änderungen an diesen Branches Pull Requests erforderlich sind. Die Pushvorgänge von Entwicklern, die Änderungen direkt an diese geschützten Branches pushen, werden zurückgewiesen.

Halten Sie Ihre Branchstrategie einfach, indem Sie Ihre Strategie auf den folgenden drei Konzepten aufbauen:

  1. Verwenden Sie Featurebranches für alle neuen Features und Fehlerkorrekturen.
  2. Mergen Sie Featurebranches mit Pull Requests in den Mainbranch.
  3. Sorgen Sie für einen stets aktuellen Mainbranch hoher Qualität.

Eine Strategie, die diese Konzepte erweitert und Widersprüche vermeidet, führt zu einem Versionskontrollworkflow für Ihr Team, der einheitlich und einfach zu befolgen ist.

Erstellen von Aufgaben in Branches

Git-Branches sind nicht viel mehr als ein kleiner Verweis, der einen genauen Verlauf von Commits enthält, sodass sie günstig zu erstellen sind.

Durch Committen von Änderungen an einem Branch werden andere Branches nicht beeinflusst. Sie können Branches mit anderen teilen, ohne die Änderungen in das Mainprojekt mergen zu müssen.

Sie können neue Branches erstellen, um Änderungen für ein Feature oder eine Fehlerkorrektur von Ihrem Mainbranch und anderen Arbeiten zu isolieren.

Aufgrund der Einfachheit von Branches ist ein schneller und einfacher Wechsel zwischen Branches möglich. Git erstellt nicht mehrere Kopien Ihres Quellcodes, wenn Sie mit Branches arbeiten. Es verwendet die in Commits enthaltenen Verlaufsinformationen, um die Dateien in einem Branch neu zu erstellen, wenn Sie beginnen, daran zu arbeiten.

Ihr Git-Workflow sollte Branches zum Verwalten von Features und Fehlerkorrekturen erstellen und verwenden.

Der gesamte Rest des Git-Workflows, z. B. das Teilen von Code und das Überprüfen von Code mit Pull Requests, wird über Branches erledigt.

Die Isolierung von Arbeiten in Branches erleichtert die Änderung, was Sie gerade bearbeiten, indem Sie Ihren aktuellen Branch ändern.

Wie werden Git-Branches erstellt?

Sie erstellen Branches mit dem branch-Befehl. Branch erstellt einen Verweis in Git für den neuen Branch und einen Zeiger zurück auf das übergeordnete Commit, damit Git beim Hinzufügen von Commits zum Branch einen Änderungsverlauf unterhalten kann.

Wenn Sie mit einem Branch arbeiten, den eine andere Person freigegeben hat, unterhält Git eine Upstream-Nachverfolgungsbeziehung. Die Beziehung ordnet den Branch im lokalen Repository dem entsprechenden Branch im Remoterepository zu.

Die Upstream-Nachverfolgung erleichtert die Synchronisierung von Änderungen mit anderen durch Push und Pull.

Visuelle Darstellung eines vom Mainbranch abgehenden Branchs in Git

In diesem Screenshot sehen Sie einen neuen Branch, der ausgehend vom Mainbranch erstellt wurde. Die Arbeit an beiden Branches wird fortgesetzt, und beiden Branches werden Commits hinzugefügt.

Git fügt dem aktuellen lokalen Branch immer neue Commits hinzu. Überprüfen Sie, an welchem Branch Sie arbeiten, bevor Sie einen Commit ausführen, damit Sie keine Änderungen in den falschen Branch committen.

Wechseln Sie mit dem checkout-Befehl zwischen lokalen Branches. Git ändert die Dateien auf Ihrem Computer dem neuesten Commit im ausgecheckten Branch entsprechend.

Wenn Ihre Arbeit im Branch für den Rest des Teams freigegeben werden kann, pushen Sie die Änderungen, um den Remotebranch zu aktualisieren.

Ein häufiger Fehler besteht darin, einige Änderungen vorzunehmen und dafür ein commit auszuführen, zu erkennen, dass Sie sich auf einem falschen Branch befinden und dann mit checkout zum richtigen Branch wechseln.

Die letzten Änderungen sind nicht mehr im Dateisystem vorhanden, da jeder Branch über eine eigene Codeversion verfügt.

Git versetzt den Status der Dateien wieder auf den letzten Commit des Branchs, zu dem Sie gewechselt sind, und nicht auf den vorherigen Branch, in den Sie Ihre Änderungen vorgenommen haben.

Sie müssen für die Commits im Branch ein Cherrypicking durchführen oder die Änderungen in den richtigen Branch mergen.

Verwenden von Branches zum Verwalten der Entwicklung

Git verfolgt, an welchem Branch Sie arbeiten, und stellt sicher, dass Ihre Dateien beim checkout-Vorgang für einen Branch mit dem letzten Commit im Branch übereinstimmen.

Branches bieten die Möglichkeit, gleichzeitig mit mehreren Versionen des Quellcodes im gleichen lokalen Git-Repository zu arbeiten.

Teilen Sie Git über checkout mit, an welchem Branch Sie arbeiten möchten. Git sorgt dann dafür, dass die richtigen Dateiversionen für diesen Branch verwendet werden.

Wenn Sie Ihre Arbeit mithilfe von Branches isolieren, benötigen Sie lediglich ein Repository auf Ihrem System.

Richten Sie Ihre Entwicklungsumgebung einmal nach dem Klonen ein. Verwenden Sie dann Git-Branches, um zwischen Featurebearbeitung und Fehlerkorrektur zu wechseln.

Branching-Anleitungen

Erfahren Sie, wie Sie allgemeine Aufgaben bei der Arbeit mit Branches ausführen.