Einführung einer Git-Verzweigungsstrategie

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

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

Teammitglieder veröffentlichen, freigeben, überprüfen und durchlaufen Codeänderungen über Git-Verzweigungen, die für andere freigegeben wurden. Übernehmen Sie eine Verzweigungsstrategie für Ihr Team. Sie können besser zusammenarbeiten und weniger Zeit mit der Verwaltung 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 Verwendung von Git bei Microsoft.

Halten Sie Ihre Zweigstrategie einfach

Halten Sie Ihre Zweigstrategie einfach. Erstellen Sie Ihre Strategie aus den folgenden drei Konzepten:

• Verwenden Sie Feature-Branches für alle neuen Features und Fehlerbehebungen.
• Zusammenführen von Feature-Verzweigungen in der Hauptzweigung mithilfe von Pullanforderungen.
• Halten Sie eine hohe Qualität, up-to-Datum Hauptverzweigung.

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

Verwenden von Featurezweigen für Ihre Arbeit

Entwickeln Sie Ihre Features, und beheben Sie Fehler in Featurezweigen basierend auf Ihrer Hauptzweigung. Diese Verzweigungen werden auch als Themenzweige bezeichnet. Feature-Verzweigungen isolieren die laufende Arbeit von der abgeschlossenen Arbeit in der Hauptzweige. Git Branches sind kostengünstig zu erstellen und zu pflegen. Auch kleine Fixes und Änderungen sollten über einen eigenen Featurezweig verfügen.

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

Benennen Ihrer Feature-Verzweigungen nach Konvention

Verwenden Sie eine konsistente Benennungskonvention für Ihre Featurezweige, um die arbeit in der Verzweigung zu identifizieren. Sie können auch weitere Informationen in den Verzweigungsnamen einschließen, z. B. wer die Verzweigung erstellt hat.

Einige Vorschläge zum Benennen Ihrer Feature-Verzweigungen:

• Benutzer/Benutzername/Beschreibung
• users/username/workitem
• bugfix/description
• Feature-/Featurename
• feature/feature-area/feature-name
• Hotfix/Beschreibung

Hinweis

Informationen zum Festlegen von Richtlinien zum Erzwingen einer Verzweigungsstrategie finden Sie unter Erforderlichkeit von Verzweigungsordnern.

Verwenden von Featurekennzeichnungen zum Verwalten langer Verzweigungen

Erfahren Sie mehr über die Verwendung von Featurekennzeichnungen in Ihrem Code.

Überprüfen und Zusammenführen von Code mit Pullanforderungen

Die Überprüfung, die in einer Pullanforderung stattfindet, ist für die Verbesserung der Codequalität von entscheidender Bedeutung. Führen Sie nur Verzweigungen über Pullanforderungen zusammen, die Ihren Überprüfungsprozess bestehen. Vermeiden Sie das Zusammenführen von Verzweigungen mit der Hauptzweigung ohne Pullanforderung.

Rezensionen in Pull-Anforderungen nehmen Zeit in Anspruch. Ihr Team sollte sich darüber einigen, was von Pull-Anforderungserstellern und Prüfern erwartet wird. Verteilen Sie die Verantwortlichkeiten des Prüfers, um Ideen in Ihrem Team zu teilen und Wissen über Ihre Codebasis zu verbreiten.

Einige Vorschläge für erfolgreiche Pullanforderungen:

• Zwei Prüfer sind eine optimale Zahl auf der Grundlage der Forschung.
• Wenn Ihr Team bereits über einen Codeüberprüfungsprozess verfügt, bringen Sie Pullanforderungen in das, was Sie bereits tun.
• Achten Sie darauf, die gleichen Bearbeiter einer großen Anzahl von Pullanforderungen zuzuweisen. Pull-Anforderungen funktionieren besser, wenn die Verantwortlichkeiten des Prüfers im gesamten Team geteilt 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 mehrstufigen Umgebung ausgeführt werden, mit Ihrer Pullanforderung. Andere können die Änderungen ganz einfach testen.

Halten Sie eine hohe Qualität, up-to-Datum Hauptzweig

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

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

• Erfordert eine Pullanforderung zum Zusammenführen von Code. Dieser Ansatz verhindert direkte Pushs an den Hauptzweig und stellt eine Diskussion über vorgeschlagene Änderungen sicher.
• 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 mit der Hauptzweigung zusammengeführt wird, sollte sauber erstellt werden.

Tipp

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

Verwalten von Releases

Verwenden Sie Release-Verzweigungen, um Änderungen in einer Version ihres Codes zu koordinieren und zu stabilisieren. Diese Verzweigung ist langlebig und wird im Gegensatz zu den Featureverzweigungen nicht mit der Hauptverzweigung in einer Pullanforderung zusammengeführt. Erstellen Sie beliebig viele Release-Verzweigungen. Beachten Sie, dass jeder aktive Release branch eine andere Version des Codes darstellt, den Sie unterstützen müssen. Lock release branches when you're ready to stop support a particular release.

Verwenden von Release-Verzweigungen

Erstellen Sie eine Release-Verzweigung aus der Hauptzweigung, wenn Sie sich ihrem Release oder einem anderen Meilenstein, z. B. dem Ende eines Sprints, nähern. Weisen Sie dieser Verzweigung einen eindeutigen Namen zu, der sie der Version zuzuordnen, z. B. Release/20.

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

Portänderungen zurück zur Hauptzweigung

Stellen Sie sicher, dass Korrekturen sowohl in Ihrer Release-Verzweigung als auch in Der Hauptzweig enthalten sind. Ein Ansatz besteht darin, Korrekturen in der Release-Verzweigung vorzunehmen und dann Änderungen in Ihre Hauptzweige zu integrieren, um Regressionen in Ihrem Code zu verhindern. Ein anderer Ansatz (und der vom Azure DevOps-Team verwendete) besteht darin, immer Änderungen an der Hauptlinie vorzunehmen und diese dann in die Release-Verzweigung zu portieren. Weitere Informationen zu unserer Release Flow-Strategie finden Sie hier.

In diesem Thema behandeln wir Änderungen am Release Branch und portieren sie in die Hauptlinie. Verwenden Sie Cherry-Pick anstelle der Zusammenführung, damit Sie genau steuern können, welche Commits wieder in den Hauptzweig portiert werden. Das Zusammenführen der Release-Verzweigung in die Hauptverzweigung kann versionsspezifische Änderungen übernehmen, die Sie nicht in der Hauptverzweigung wünschen.

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

1. Erstellen Sie eine neue Feature-Verzweigung aus der Hauptzweigung, um die Änderungen zu portieren.
2. Übertragen Sie gezielt die Änderungen aus dem Release-Branch in Ihren neuen Feature-Branch.
3. Führen Sie die Feature-Verzweigung in einer zweiten Pullanforderung wieder in die Hauptzweigung ein.

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

Warum keine Tags für Versionen verwenden?

Andere Verzweigungsworkflows verwenden Git-Tags , um einen bestimmten Commit als Version zu kennzeichnen. 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 Verzweigungen für Ihre Versionen verwenden.

Tags werden getrennt von Ihren Commits verwaltet und verschoben. Teammitglieder können das Kategorisieren eines Commits ganz einfach verpassen und dann den Verlauf später erneut durchlaufen, um das Tag zu beheben. Sie können auch den zusätzlichen Schritt vergessen, um das Tag zu pushen, sodass der nächste Entwickler von einer älteren Version des Codes arbeitet, wenn die Version unterstützt wird.

Die Release Branch-Strategie erweitert den grundlegenden Featurezweigworkflow zur Behandlung von Versionen. Ihr Team muss keinen anderen Prozess zur Versionssteuerung übernehmen als die Cherry-Pick zum Portieren von Änderungen.

Verwalten von Bereitstellungen

Sie können mehrere Bereitstellungen Ihres Codes auf die gleiche Weise behandeln, wie Sie mehrere Versionen behandeln. Erstellen Sie eine klare Benennungskonvention, z. B. bereitstellen/performance-test, und behandeln Sie die Umgebungsverzweigungen wie Release Branches. Ihr Team sollte sich auf einen Prozess zum Aktualisieren von Bereitstellungszweigen mit dem Code ihrer Hauptzweige einigen. Cherry-pick Bug fixes in the deployment branch back to the main branch. Führen Sie dieselben Schritte wie das Portieren von Änderungen aus einer Release-Verzweigung aus.

Eine Ausnahme dieser Empfehlung ist, wenn Sie eine Form der kontinuierlichen Bereitstellung verwenden. Verwenden Sie Azure-Pipelines , wenn Sie mit einer kontinuierlichen Bereitstellung arbeiten, um Builds von Ihrer Hauptzweigstelle bis zu Ihren Bereitstellungszielen zu fördern.