Übernehmen einer Git-Verzweigungsstrategie

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Verteilte Versionssteuerungssysteme wie Git bieten Ihnen Flexibilität bei der Verwendung von Versionssteuerung zum Freigeben und Verwalten von Code. Ihr Team sollte eine Balance zwischen dieser Flexibilität und der Notwendigkeit finden, Code auf einheitliche Weise zusammenzuarbeiten und gemeinsam zu teilen.

Teammitglieder veröffentlichen, freigeben, überprüfen und auf Codeänderungen durch Git-Zweigen, die für andere freigegeben wurden, iterieren. Nehmen Sie eine Verzweigungsstrategie für Ihr Team an. Sie können besser zusammenarbeiten und weniger Zeit beim Verwalten der Versionssteuerung und mehr Zeit beim Entwickeln von Code verbringen.

Die folgenden Verzweigungsstrategien basieren auf der Art und Weise, wie wir Git hier bei Microsoft verwenden. Weitere Informationen finden Sie unter "Wie wir Git bei Microsoft verwenden".

Einfache Verzweigungsstrategie

Behalten Sie Ihre Zweigstrategie einfach. Erstellen Sie Ihre Strategie aus diesen drei Konzepten:

  • Verwenden Sie Featurebranches für alle neuen Features und Fehlerkorrekturen.
  • Zusammenführen von Featurezweigen in den Hauptzweig mithilfe von Pullanforderungen.
  • Halten Sie eine hohe Qualität, auf dem neuesten Hauptzweig.

Eine Strategie, die diese Konzepte erweitert und Widerspruche vermeiden, führt zu einem Versionssteuerungsworkflow für Ihr Team, das konsistent und einfach zu folgen ist.

Verwenden von Featurezweigen für Ihre Arbeit

Entwickeln Sie Ihre Features und beheben Sie Fehler in Funktionszweigen basierend auf Ihrem Hauptzweig. Diese Zweige werden auch als Themenzweige bezeichnet. Funktionszweige isolieren Die Arbeit wird von der abgeschlossenen Arbeit in der Hauptzweige isoliert. Git-Zweigstellen sind kostengünstig, um zu erstellen und zu verwalten. Selbst kleine Fixes und Änderungen sollten über einen eigenen Featurezweig verfügen.

Abbildung des grundlegenden Verzweigungsworkflows

Das Erstellen von Featurezweigen für alle Ihre Änderungen macht das Überprüfen des Verlaufs einfach. Schauen Sie sich die in der Verzweigung vorgenommenen Commits an und sehen Sie sich die Pullanforderung an, die die Verzweigung zusammengeführt hat.

Benennen Sie Ihre Featurezweige nach Konvention

Verwenden Sie eine konsistente Benennungskonvention für Ihre Featurezweige, um die Arbeit in der Zweigstelle zu identifizieren. Sie können auch andere Informationen in den Zweignamen einschließen, z. B. wer den Zweig erstellt hat.

Einige Vorschläge zum Benennen Ihrer Feature-Zweigstellen:

  • Benutzer/Benutzername/Beschreibung
  • Benutzer/Benutzername/Arbeitselement
  • Bugfix/Beschreibung
  • Feature-/Featurename
  • feature/feature-area/feature-name
  • Hotfix/Beschreibung

Hinweis

Informationen zum Festlegen von Richtlinien zum Erzwingen einer Verzweigungsstrategie finden Sie unter "Anfordern von Zweigordnern".

Verwenden von Feature-Flags zum Verwalten von lang ausgeführten Zweigen

Erfahren Sie mehr über die Verwendung von Feature-Flags in Ihrem Code.

Überprüfen und Zusammenführen von Code mit Pull Requests

Die Überprüfung, die in einer Pull-Anforderung stattfindet, ist für die Verbesserung der Codequalität wichtig. Zusammenführen von Zweigen durch Pull-Anforderungen, die Ihren Überprüfungsprozess übergeben. Vermeiden Sie das Zusammenführen von Zweigen mit dem Hauptzweig ohne Pullanforderung.

Bewertungen in Pull-Anforderungen nehmen Zeit für den Abschluss. Ihr Team sollte sich auf das festlegen, was von Pull Request Creators und Reviewern erwartet wird. Verteilen Sie Prüfer-Zuständigkeiten, um Ideen über Ihr Team hinweg zu teilen und Wissen über Ihre Codebase zu verbreiten.

Einige Vorschläge für erfolgreiche Pullanforderungen:

  • Zwei Prüfer sind eine optimale Zahl basierend auf Forschung.
  • Wenn Ihr Team bereits über einen Codeüberprüfungsprozess verfügt, bringen Sie Pull-Anforderungen in die bereits ausgeführten Aktionen ein.
  • Achten Sie darauf, den gleichen Prüfern eine große Anzahl von Pullanforderungen zuzuweisen. Pull-Anforderungen funktionieren besser, wenn Prüfer-Zuständigkeiten im gesamten Team gemeinsam genutzt werden.
  • Stellen Sie genügend Details in der Beschreibung bereit, um Prüfer schnell mit Ihren Änderungen zu beschleunigen.
  • Fügen Sie eine Build- oder verknüpfte Version Ihrer Änderungen ein, die in einer phasenierten Umgebung mit Ihrer Pullanforderung ausgeführt werden. Andere können die Änderungen einfach testen.

Halten Sie eine hohe Qualität, auf dem neuesten Hauptzweig

Der Code in Ihrem Hauptzweig sollte Tests übergeben, sauber erstellen und immer aktuell sein. Ihre Hauptzweige benötigt diese Qualitäten, damit Funktionszweige, die von Ihrem Team erstellt wurden, aus einer bekannten guten Codeversion beginnen.

Richten Sie eine Zweigrichtlinie für Ihre Hauptzweige ein, die:

  • Erfordert eine Pullanforderung zum Zusammenführen von Code. Dieser Ansatz verhindert direkte Pushe an den Hauptzweig und gewährleistet die Diskussion der vorgeschlagenen Änderungen.
  • Fügt Prüfer automatisch hinzu, wenn eine Pullanforderung erstellt wird. Die hinzugefügten Teammitglieder überprüfen den Code und kommentieren die Änderungen in der Pullanforderung.
  • Erfordert einen erfolgreichen Build, um eine Pullanforderung abzuschließen. Code, der in den Hauptzweig zusammengeführt wird, sollte sauber erstellt werden.

Tipp

Die Buildpipeline für Ihre Pullanforderungen sollte schnell abgeschlossen sein, sodass es den Überprüfungsprozess nicht beeinträchtigt.

Verwalten von Versionen

Verwenden Sie Release-Verzweigungen, um Änderungen in einer Version Ihres Codes zu koordinieren und zu stabilisieren. Dieser Zweig ist langlebig und wird nicht in den Hauptzweig in einer Pull-Anforderung zusammengeführt, im Gegensatz zu den Featurezweigen. Erstellen Sie so viele Release-Zweigstellen, wie Sie benötigen. Beachten Sie, dass jede aktive Release-Verzweigung eine andere Version des Codes darstellt, den Sie unterstützen müssen. Sperrversionszweige, wenn Sie bereit sind, die Unterstützung einer bestimmten Version zu beenden.

Verwendung von Releasebranches

Erstellen Sie einen Release-Zweig aus dem Hauptzweig, wenn Sie sich mit Ihrer Version oder einem anderen Meilenstein, z. B. dem Ende eines Sprints, nähern. Geben Sie dieser Verzweigung einen eindeutigen Namen, der sie mit der Version verknüpft, z. B. Release/20.

Erstellen Sie Verzweigungen, um Fehler aus der Release-Verzweigung zu beheben, und führen Sie sie wieder in die Release-Branch in einer Pullanforderung zusammen.

Abbildung der Release-Zweigworkflows

Portänderungen zurück zum Hauptzweig

Stellen Sie sicher, dass Korrekturen sowohl in Ihrer Release-Verzweigung als auch in Ihrem Hauptzweig landen. Ein Ansatz besteht darin, Korrekturen in der Release-Verzweigung vorzunehmen, und dann Änderungen in Ihre Hauptzweige zu bringen, um die Regression in Ihrem Code zu verhindern. Ein anderer Ansatz (und das von dem Azure DevOps-Team verwendete) besteht darin, immer Änderungen in der Hauptlinie vorzunehmen, und portieren Sie dies dann an den Release-Branch. Sie können mehr über unsere Release Flow-Strategie lesen.

In diesem Thema werden änderungen in der Release-Verzweigung vorgenommen und in Hauptlinie portiert. Verwenden Sie die Kirschauswahl anstelle der Zusammenführung, sodass Sie genaue Kontrolle darüber haben, welche Commits wieder in den Hauptzweig portiert werden. Das Zusammenführen des Featurezweigs in den Hauptzweig kann versionsspezifische Änderungen vornehmen, die Sie nicht in der Hauptzweigung wünschen.

Aktualisieren Sie die Hauptzweige mit einer Änderung, die in der Release-Verzweigung vorgenommen wurde, mit den folgenden Schritten:

  1. Erstellen Sie einen neuen Featurezweig aus dem Hauptzweig, um die Änderungen zu portieren.
  2. Cherry-Pick the changes from the release branch to your new feature branch.
  3. Zusammenführen Sie den Featurezweig wieder in den Hauptzweig in einer zweiten Pull-Anforderung.

Aktualisierte Release-Verzweigungsworkflows.

Dieser Release-Branch-Workflow behält die Säulen des grundlegenden Workflows intakt: Funktionszweige, Pullanforderungen und eine starke Hauptzweige, die immer über die neueste Version des Codes verfügt.

Warum verwenden Sie keine Tags für Versionen?

Andere Verzweigungsworkflows verwenden Git-Tags , um einen bestimmten Commit als Version zu markieren. Tags sind nützlich, um Punkte in Ihrem Verlauf als wichtig zu markieren. Tags führen zusätzliche Schritte in Ihrem Workflow ein, die nicht erforderlich sind, wenn Sie Zweigstellen für Ihre Versionen verwenden.

Tags werden getrennt von Ihren Commits beibehalten und verschoben. Teammitglieder können es einfach verpassen, einen Commit zu markieren und dann wieder über den Verlauf zurückzukehren, um das Tag zu beheben. Sie können auch den zusätzlichen Schritt vergessen, um das Tag zu verschieben, indem der nächste Entwickler aus einer älteren Version des Codes arbeitet, wenn die Version unterstützt wird.

Die Version branch-Strategie erweitert den grundlegenden Funktionszweigworkflow, um Versionen zu behandeln. Ihr Team muss keinen anderen Versionskontrollesprozess als die Kirschauswahl für Portierungsänderungen übernehmen.

Verwalten von Bereitstellungen

Sie können mehrere Bereitstellungen Ihres Codes auf dieselbe Weise behandeln, wie Sie mehrere Versionen behandeln. Erstellen Sie eine klare Benennungskonvention, z. B. deploy/performance-test, und behandeln Sie die Umgebungszweige wie Release-Zweigen. Ihr Team sollte sich auf einen Prozess zum Aktualisieren von Bereitstellungszweigen mit dem Code aus Ihrem Hauptzweig einigen. Cherry-Pick-Fehlerkorrekturen in der Bereitstellungszweig zurück zum Hauptzweig. Verwenden Sie die gleichen Schritte wie die Portierung von Änderungen aus einem Release branch.

Eine Ausnahme dieser Empfehlung ist, wenn Sie eine Form der kontinuierlichen Bereitstellung verwenden. Verwenden Sie Azure-Pipelines , wenn Sie mit fortlaufender Bereitstellung arbeiten, um Builds von Ihrem Hauptzweig auf Ihre Bereitstellungsziele zu fördern.

Videos