Übernehmen einer Git-Verzweigungsstrategie

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

Verteilte Versionskontrollsysteme wie Git ermöglichen die flexible Verwendung der Versionskontrolle für das Teilen und Verwalten von Code. Ihr Team sollte ein ausgewogenes Verhältnis zwischen dieser Flexibilität und der Notwendigkeit finden, konsistent zusammenzuarbeiten und Code zu teilen.

Teammitglieder veröffentlichen, teilen, überprüfen und durchlaufen Codeänderungen über Git-Branches, die für andere freigegeben wurden. Nutzen Sie eine Branchingstrategie für Ihr Team. Sie können besser zusammenarbeiten und den Zeitaufwand für die Verwaltung der Versionskontrolle verringern, sodass Sie mehr Zeit für die Codeentwicklung haben.

Die folgenden Branchingstrategien basieren auf der Verwendung von Git bei Microsoft. Weitere Informationen finden Sie im Artikel zur Verwendung von Git bei Microsoft.

Implementieren einer einfachen Branchstrategie

Halten Sie Ihre Branchstrategie einfach. Erstellen Sie Ihre Strategie aufbauend auf den folgenden drei Konzepten:

• Verwenden Sie Featurebranches für alle neuen Features und Fehlerkorrekturen.
• Mergen Sie Featurebranches mit Pull Requests in den Mainbranch.
• 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.

Verwenden von Featurebranches für Ihre Arbeit

Entwickeln Sie Ihre Features und Bugfixes in Featurebranches, die auf Ihrem Mainbranch basieren. Diese Branches werden auch als Topic-Branches bezeichnet. Featurebranches isolieren die laufende Arbeit von der erledigten Arbeit im Mainbranch. Git-Branches lassen sich kostengünstig erstellen und verwalten. Selbst kleine Fixes und Änderungen sollten über einen eigenen Featurebranch verfügen.

Das Erstellen von Featurebranches für alle Ihre Änderungen erleichtert die Überprüfung des Verlaufs. Sehen Sie sich dazu die Commits im Branch und den Pull Request für das Mergen des Branchs.

Verwenden einer Benennungskonvention für Ihre Featurebranches

Verwenden Sie eine einheitliche Benennungskonvention für Ihre Featurebranches, um die im Branch geleistete Arbeit zu kennzeichnen. Sie können auch andere Informationen in den Branchnamen einbeziehen, z. B. wer den Branch erstellt hat.

Einige Vorschläge zum Benennen Ihrer Featurebranches:

• Benutzer/Benutzername/Beschreibung
• Benutzer/Benutzername/Arbeitselement
• Bugfix/Beschreibung
• Feature/Featurename
• Feature/Featurebereich/Featurename
• Hotfix/Beschreibung

Hinweis

Informationen zum Festlegen von Richtlinien zum Erzwingen einer Benennungsstrategie für Branches finden Sie unter Erfordern, dass Verzweigungen in Ordnern erstellt werden sollen.

Verwenden von Featureflags, um Langzeitbranches zu verwalten

Erfahren Sie mehr über Verwendung von Featureflags in Ihrem Code.

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

Die Überprüfung, die in einem Pull Request stattfindet, ist entscheidend für die Verbesserung der Codequalität. Mergen Sie nur Branches über Pull Requests, die den Überprüfungsprozess bestehen. Vermeiden Sie das Mergen von Branches mit dem Mainbranch ohne einen Pull Request.

Überprüfungen in Pull Requests nehmen einige Zeit in Anspruch. Ihr Team sollte festlegen, was von den Erstellern und Prüfern von Pull Requests erwartet wird. Verteilen Sie die Verantwortlichkeiten des Prüfers, um Ideen in Ihrem Team zu teilen und das Wissen über Ihre Codebasis zu auszubreiten.

Einige Vorschläge für erfolgreiche Pull Requests:

• Zwei Prüfer sind eine optimale Zahl, wie die Forschung gezeigt hat.
• Wenn Ihr Team bereits über einen Codeüberprüfungsprozess verfügt, integrieren Sie Pull Requests in die bestehende Vorgehensweise.
• Seien Sie vorsichtig, wenn Sie die gleichen Prüfer einer großen Anzahl von Pull-Anfragen zuweisen. Pull Requests funktionieren besser, wenn die Verantwortlichkeiten der Prüfer auf das ganze Team verteilt werden.
• Geben Sie genügend Details in der Beschreibung an, damit die Prüfer mit Ihren Änderungen Schritt halten können.
• Schließen Sie einen Build- oder eine verknüpfte Version Ihrer Änderungen, die in einer gestageten Umgebung ausgeführt werden, in Ihren Pull Request ein. Andere können die Änderungen problemlos testen.

Gewährleisten eines stets aktuellen Mainbranchs mit hoher Qualität

Der Code in Ihrem Mainbranch sollte Tests bestehen, sauber kompiliert werden und immer aktuell sein. Die Qualität ist für Ihren Mainbranch von entscheidender Bedeutung, damit von Ihrem Team erstellte Featurebranches eine bekanntermaßen einwandfreie Codeversion verwenden.

Richten Sie eine Branchrichtlinie für Ihren Mainbranch mit folgenden Eigenschaften ein:

• Zum Zusammenführen von Code ist ein Pull Request erforderlich. Dadurch werden direkte Pushvorgänge an den Mainbranch verhindert, und die Diskussion der vorgeschlagenen Änderungen wird sichergestellt.
• Beim Erstellen eines Pull Requests werden automatisch Prüfer hinzugefügt. Die hinzugefügten Teammitglieder überprüfen den Code und kommentieren die Änderungen im Pull Request.
• Für einen Pull Request ist ein erfolgreicher Build erforderlich. Code, der in den Mainbranch gemergt wird, sollte fehlerfrei kompiliert werden.

Tipp

Die Buildpipeline für Ihre Pull Requests sollte in kurzer Zeit ausgeführt werden, damit sie den Überprüfungsprozess nicht beeinträchtigt.

Verwalten von Releases

Verwenden Sie Releasebranches, um Änderungen in einer Codeversion zu koordinieren und zu stabilisieren. Dieser Branch ist langlebig und wird im Gegensatz zu den Featurebranches in einem Pull Request nicht wieder in den Mainbranch gemergt. Sie können so viele Releasebranches erstellen wie nötig. Beachten Sie, dass jeder aktive Releasebranch eine andere Version des Codes darstellt, die Sie unterstützen müssen. Sperren Sie Releasebranches, wenn die Unterstützung für ein bestimmtes Release beendet werden kann.

Verwendung von Releasebranches

Erstellen Sie einen Releasebranch aus dem Mainbranch, wenn Sie Ihr Release oder ein anderer Meilenstein, z. B. das Ende eines Sprints, fast erreicht ist. Weisen Sie diesem Branch einen eindeutigen Namen zu, der ihn dem Release zuordnet, z. B. release/20.

Erstellen Sie Branches zum Beheben von Fehlern aus dem Releasebranch, und mergen Sie sie in einem Pull Request wieder in den Releasebranch.

Portieren von Änderungen zurück in den Mainbranch

Stellen Sie sicher, dass Fixes sowohl in Ihrem Releasebranch als auch in Ihrem Mainbranch landen. Eine Möglichkeit dafür besteht darin, Fixes im Releasebranch vorzunehmen und Änderungen dann in Ihren Mainbranch zu übernehmen, um eine Regression im Code zu verhindern. Eine andere Möglichkeit (der vom Azure DevOps-Team verwendet wird) besteht darin, Änderungen immer in der Mainline vorzunehmen und diese dann in den Releasebranch zu portieren. Weitere Informationen zu unserer Releaseflowstrategie finden Sie hier.

In diesem Thema erfahren Sie, wie Sie Änderungen im Releasebranch vornehmen und in die Mainline portieren. Verwenden Sie Cherrypicking anstelle von Mergevorgängen, damit Sie genau steuern können, welche Commits zurück in den Mainbranch portiert werden. Das Zusammenführen des Releasebranch mit dem Mainbranch kann versionsspezifische Änderungen nach sich ziehen, die Sie im Mainbranch nicht durchführen möchten.

Führen Sie die folgenden Schritte aus, um den Mainbranch mit einer Änderung zu aktualisieren, die im Releasebranch vorgenommen wurde:

1. Erstellen Sie einen neuen Featurebranch ausgehend vom Mainbranch, um die Änderungen zu portieren.
2. Führen Sie ein Cherrypicking für die Änderungen vom Releasebranch in den neuen Featurebranch aus.
3. Mergen Sie den Featurebranch in einem zweiten Pull Request wieder in den Mainbranch.

Bei diesem Releasebranchworkflow bleiben die Säulen des grundlegenden Workflows erhalten: Featurebranches, Pull Requests und ein solider Mainbranch, der immer über die neueste Version des Codes verfügt.

Warum keine Tags für Releases verwendet werden sollten

Andere Branchingworkflows verwenden Git-Tags, um einen bestimmten Commit als Release zu markieren. Tags sind nützlich, um Punkte in Ihrem Verlauf als bedeutsam zu markieren. Tags führen zusätzliche Schritte in Ihren Workflow ein, die nicht erforderlich sind, wenn Sie Branches für Ihre Releases verwenden.

Tags werden getrennt von Ihren Commits verwaltet und gepusht. Teammitglieder können leicht vergessen, einen Commit zu taggen, und müssen anschließend den Verlauf durchgehen, um das Tag zu korrigieren. Sie können auch den zusätzlichen Schritt zum Pushen des Tags vergessen, sodass der nächste Entwickler bei der Unterstützung des Release mit einer älteren Codeversion arbeitet.

Die Releasebranchstrategie erweitert den grundlegenden Featurebranchworkflow für die Handhabung von Releases. Ihr Team muss lediglich das Cherrypicking als neuen Versionsverwaltungsprozess einführen, um Änderungen zu portierten.

Verwalten von Bereitstellungen

Sie können mehrere Bereitstellungen Ihres Codes genauso handhaben wie mehrere Releases. Erstellen Sie eine klare Benennungskonvention, z. B. Bereitstellen/Leistungstest, und behandeln Sie die Umgebungsbranches wie Releasebranches. Ihr Team sollte einen Prozess zum Aktualisieren von Bereitstellungsbranchen mit dem Code aus dem Mainbranch vereinbaren. Führen Sie für Bugfixes ein Cherrypicking im Bereitstellungsbranch zurück in den Mainbranch aus. Führen Sie dieselben Schritte wie beim Portieren von Änderungen aus einem Releasebranch aus.

Eine Ausnahme von dieser Empfehlung ist die Verwendung einer Art von Continuous Deployment. Verwenden Sie Azure Pipelines, wenn Sie Continuous Deployment verwenden, um Builds aus Ihrem Mainbranch in Ihre Bereitstellungsziele hochzustufen.