Übernehmen einer Git-Verzweigungsstrategie

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Verteilte Versionssteuerungssysteme wie Git bieten Ihnen Flexibilität bei der Verwendung der Versionssteuerung zum Freigeben und Verwalten von Code. Ihr Team sollte eine Balance zwischen dieser Flexibilität und der Notwendigkeit finden, Code einheitlich zu zusammenarbeiten 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 Zweigstellenstrategie einfach

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

• Verwenden Sie Featurebranches für alle neuen Features und Fehlerkorrekturen.
• Zusammenführen von Funktionszweigen in die Hauptzweigung mithilfe von Pullanforderungen.
• Halten Sie eine hochwertige, aktuelle Hauptzweigung.

Eine Strategie, die diese Konzepte erweitert und Widerspruche vermeidet, führt zu einem Versionsverwaltungsworkflow 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 Featurezweigen basierend auf Ihrer Hauptzweige. Diese Verzweigungen werden auch als Themenzweige bezeichnet. Feature-Verzweigungen isolieren Die Arbeit wird von der abgeschlossenen Arbeit in der Hauptzweigung isoliert. Git-Verzweigungen sind kostengünstig, um sie zu erstellen und zu verwalten. Selbst kleine Fixes und Änderungen sollten über einen eigenen Featurezweig verfügen.

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

Benennen Ihrer Featurezweige 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 Featurezweige:

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

Hinweis

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

Verwenden von Featurekennzeichnungen zum Verwalten von lang ausgeführten Verzweigungen

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

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

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 übergeben. Vermeiden Sie das Zusammenführen von Verzweigungen mit dem Hauptzweig ohne Pullanforderung.

Rezensionen in Pullanforderungen dauern bis zur Fertigstellung. Ihr Team sollte sich darüber einig sein, was von Pull-Request-Erstellern 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 basierend auf 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 Prüfer einer großen Anzahl von Pullanforderungen zuzuweisen. Pull-Anforderungen funktionieren besser, wenn Prüfer-Verantwortlichkeiten im gesamten Team gemeinsam genutzt werden.
• Geben Sie genügend Details in der Beschreibung an, um Prüfer schnell mit Ihren Änderungen zu beschleunigen.
• Fügen Sie eine Build- oder verknüpfte Version Ihrer Änderungen ein, die in einer phasengebundenen Umgebung ausgeführt werden, mit Ihrer Pullanforderung. Andere können die Änderungen problemlos testen.

Halten Sie einen hochwertigen, aktuellen Hauptzweig

Der Code in Ihrer Hauptzweigung sollte Tests übergeben, sauber erstellen und immer aktuell sein. Ihre Hauptzweige benötigt diese Qualitäten, damit Funktionszweige, die von Ihrem Team erstellt werden, 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 Pushes 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 Versionen

Verwenden Sie Release-Verzweigungen, um Änderungen in einer Version des Codes zu koordinieren und zu stabilisieren. Diese Verzweigung ist langlebig und wird nicht in die Hauptverzweigung in einer Pullanforderung zusammengeführt, im Gegensatz zu den Featurezweigen. Erstellen Sie beliebig viele Release-Verzweigungen. Beachten Sie, dass jeder aktive Releasezweig eine andere Version des Codes darstellt, den Sie unterstützen müssen. Sperren Sie Release-Verzweigungen, wenn Sie die Unterstützung einer bestimmten Version beenden möchten.

Verwendung von Releasebranches

Erstellen Sie einen Release branch aus der Hauptzweigung, wenn Sie sich ihrer Version oder einem anderen Meilenstein nähern, z. B. das Ende eines Sprints. Weisen Sie dieser Verzweigung einen eindeutigen Namen zu, 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 in einer Pullanforderung wieder in den Release branch zusammen.

Portänderungen zurück an den Hauptzweig

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

In diesem Thema werden Änderungen an der Release-Verzweigung vorgenommen und in die Hauptlinie portiert. Verwenden Sie die Kirschauswahl, anstatt zusammenzuführen, damit Sie genau steuern können, welche Commits wieder in den Hauptzweig portiert werden. Das Zusammenführen der Featureverzweigung in die Hauptverzweigung kann versionsspezifische Änderungen, die Sie nicht in der Hauptzweigung wünschen, überbringen.

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

1. Erstellen Sie einen neuen Featurezweig aus der Hauptzweigung, um die Änderungen zu portieren.
2. Cherry-pick the changes from the release branch to your new feature branch.
3. Verbinden Sie den Featurezweig wieder in die Hauptzweigung in einer zweiten Pullanforderung.

Dieser Release Branch-Workflow behält die Säulen des grundlegenden Workflows intakt: Featurezweige, 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 Verzweigungen für Ihre Versionen verwenden.

Tags werden getrennt von Ihren Commits verwaltet und verschoben. Teammitglieder können das Kennzeichnen eines Commits ganz einfach verpassen und müssen dann den Verlauf später wieder durchlaufen, um das Tag zu beheben. Sie können auch den zusätzlichen Schritt vergessen, um das Tag zu pushen, wodurch der nächste Entwickler von 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