Erkunden des Git-Verzweigungsmodells für Continuous Delivery

3 Minuten

Der Zweck des Schreibens von Code besteht darin, Verbesserungen an Ihrer Software vorzunehmen.

Ein Branchmodell, das zu viel Prozessaufwand erfordert, trägt nicht dazu bei, den Eingang von Änderungen bei den Kunden zu beschleunigen – durch das Entwickeln eines Branchmodells erhalten Sie genügend Polster, sodass keine Änderungen minderer Qualität geliefert werden. Gleichzeitig werden aber auch nicht zu viele Prozesse eingeführt, die Sie ausbremsen.

Das Internet ist voll von Verzweigungsstrategien für Git. Es gibt zwar kein Richtig oder Falsch, aber eine perfekte Verzweigungsstrategie funktioniert für Ihr Team!

Sie werden lernen, die Kombination von Featurebranches und Pull Requests zu verwenden, um einen versandbereiten Mainbranch zu erhalten.

Vorbereitung

Im Folgenden werden die Prinzipien unserer Vorschläge behandelt:

Mainbranch:
- Der Mainbranch ist die einzige Möglichkeit, etwas für die Produktion freizugeben.
- Der Mainbranch sollte sich immer in einem für die Freigabe bereiten Zustand befinden.
- Schützen Sie den Mainbranch mit Branchrichtlinien.
- Alle Änderungen am Mainbranch erfolgen ausschließlich über Pull Requests.
- Markieren Sie alle Releases im Mainbranch mit Git-Tags.
Featurebranch:
- Verwenden Sie Featurebranches für alle neuen Features und Fehlerkorrekturen.
- Verwenden Sie Featureflags, um zeitintensive Featurebranches zu verwalten.
- Änderungen von Featurebranches am Mainbranch erfolgen nur über Pull Requests.
- Benennen Sie Ihr Feature seinem Zweck entsprechend.
Die Release-Verzweigung:
- Erstellen Sie eine dedizierte Release-Verzweigung aus einer stabilen Feature-Verzweigung, um sich auf die Bereitstellung vorzubereiten.
- Stellen Sie sicher, dass die Release-Verzweigung gründlich getestet und stabilisiert wird.
- Wenden Sie Fehlerkorrekturen und erforderliche Änderungen an der Release-Verzweigung vor der Bereitstellung an.
- Markieren Sie Versionen in der Release-Verzweigung, um wichtige Meilensteine zu markieren.
Liste der Branches:
```
bugfix/description
features/feature-name
features/feature-area/feature-name
hotfix/description
users/username/description
users/username/workitem
```
Pull Requests:
- Überprüfen Sie den Code, und führen Sie ihn mit Pull Requests zusammen.
- Automatisieren Sie, was Sie im Rahmen von Pull Requests untersuchen und überprüfen.
- Verfolgen Sie die Dauer der Fertigstellung von Pull Requests nach und legen Sie Ziele fest, um die erforderliche Zeit zu verkürzen.

Wir verwenden die in den vorherigen Übungen erstellte myWebApp. Weitere Informationen finden Sie unter Lokales Arbeiten mit Git.

In diesem Rezept verwenden wir auch drei angesagte Erweiterungen aus dem Marketplace:

Azure CLI: Dies ist eine Befehlszeilenschnittstelle für Azure.
Azure DevOps CLI: ist eine Erweiterung der Azure-Befehlszeilenschnittstelle für die Arbeit mit Azure DevOps und Azure DevOps Server, die für die nahtlose Integration mit Git, CI-Pipelines und Agile-Tools entwickelt wurde. Mit der Azure DevOps CLI können Sie zu Ihren Projekten beitragen, ohne die Befehlszeile zu verlassen. Die CLI kann unter Windows, Linux und Mac ausgeführt werden.
Git-Pull Request-Zusammenführungskonflikt: Diese von Microsoft DevLabs erstellte Open-Source-Erweiterung ermöglicht Ihnen, Konflikte bei der Zusammenführung von Pull Requests über das Internet zu überprüfen und zu beheben. Bevor ein Git-Pull Request abgeschlossen werden kann, müssen alle Konflikte mit dem Zielbranch behoben werden. Mit dieser Erweiterung können Sie diese Konflikte im Web als Teil der Zusammenführung von Pull Requests beheben, anstatt die Zusammenführung und Konfliktlösung in einem lokalen Klon durchzuführen.

Die Azure DevOps CLI unterstützt die Rückgabe der Abfrageergebnisse in den Formaten JSON, JSONC, YAML, YAMLC, Tabelle und TSV sowie ohne Format (none). Sie können Ihre Präferenz mithilfe des „configure“-Befehls konfigurieren.

Vorgehensweise

Wichtig

Sie benötigen das Projekt, das Sie im ersten Lernpfad Lokales Arbeit mit Git erstellt haben.

Nachdem Sie den Mainbranch in ein lokales Repository geklont haben, erstellen Sie einen neuen Featurebranch, „myFeature-1“:

myWebApp
```
git checkout -b feature/myFeature-1
```
Ausgabe:

Switched to a new branch 'feature/myFeature-1'.
Führen Sie den Git-Branchbefehl aus, um alle Branches anzuzeigen. Der mit einem Stern gekennzeichnete Branch ist der zurzeit ausgecheckte Branch (currently-checked-out):

myWebApp
```
git branch
```
Ausgabe:

feature/myFeature-1

main
Ändern Sie die Datei „Program.cs“ im Branch „feature/myFeature-1“:

myWebApp
```
notepad Program.cs
```
Stagen Sie Ihre Änderungen, und führen Sie den Commit lokal durch. Dann veröffentlichen Sie Ihren Branch an einem Remotespeicherort:

myWebApp
```
git status
```
Ausgabe:

On branch feature/myFeature-1 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: Program.cs.

myWebApp
```
git add .
git commit -m "Feature 1 added to Program.cs"
```
Ausgabe:

[feature/myFeature-1 70f67b2] feature 1 added to program.cs 1 file changed, 1 insertion(+).

myWebApp
```
git push -u origin feature/myFeature-1
```
Ausgabe:

Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 348 bytes | 348.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: Analyzing objects... (3/3) (10 ms) remote: Storing packfile... done (44 ms) remote: Storing index... done (62 ms) To https://dev.azure.com/organization/teamproject/\_git/MyWebApp * [new branch] feature/myFeature-1 -> feature/myFeature-1 Branch feature/myFeature-1 set up to track remote branch feature/myFeature-1 from origin.

Der Remotespeicherort zeigt den Verlauf der Änderungen an:
Konfigurieren Sie die Azure DevOps CLI für Ihre Organisation und Ihr Projekt. Ersetzen Sie Organisation und Projektname:
```
az devops configure --defaults organization=https://dev.azure.com/organization project="project name"
```
Erstellen Sie einen neuen Pull Request (mithilfe der Azure DevOps CLI), um die Änderungen im Branch „feature-1“ zu überprüfen:
```
az repos pr create --title "Review Feature-1 before merging to main" --work-items 38 39 `
--description "#Merge feature-1 to main" `
--source-branch feature/myFeature-1 --target-branch main `
--repository myWebApp --open
```
Verwenden Sie den Schalter „--open“, wenn Sie den Pull Request auslösen, um ihn nach der Erstellung in einem Webbrowser zu öffnen. Der Schalter „--deletesource-branch“ kann verwendet werden, um den Branch nach Abschluss des Pull Requests zu löschen. Erwägen Sie außerdem die Verwendung von „--auto-complete“ für den automatischen Abschluss, wenn alle Richtlinien erfüllt sind und der Quellbranch mit dem Zielbranch zusammengeführt werden kann.

Hinweis

Weitere Informationen zum Parameter az repos pr create finden Sie unter Erstellen eines Pull Requests zum Überprüfen und Mergen von Code.

Das Team überprüft gemeinsam die Codeänderungen und genehmigt den Pull Request:

Der Mainbranch kann jetzt freigegeben werden. Das Team markiert den Mainbranch mit der Releasenummer:
Beginnen Sie mit der Arbeit an Feature 2. Erstellen Sie einen Branch an einem Remotespeicherort aus dem Mainbranch, und führen Sie das Auschecken lokal durch:

myWebApp
```
git push origin main:refs/heads/feature/myFeature-2
```
Ausgabe:

Total 0 (delta 0), reused 0 (delta 0) To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] origin/HEAD -> refs/heads/feature/myFeature-2.

myWebApp
```
git checkout feature/myFeature-2
```
Ausgabe:

Switched to a new branch 'feature/myFeature-2' Branch feature/myFeature-2 set up to track remote branch feature/myFeature-2 from origin.

Ändern Sie die Datei „Program.cs“, indem Sie die gleiche Kommentarzeile im Code ändern, die in „feature-1“ geändert wurde.

public class Program
{
    // Editing the same line (file from feature-2 branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

Committen Sie die Änderungen lokal, pushen Sie sie in das Remoterepository, und lösen Sie dann einen Pull Request aus, um die Änderungen von „feature/myFeature-2“ mit dem Mainbranch zu mergen:
```
az repos pr create --title "Review Feature-2 before merging to main" --work-items 40 42 `
--description "#Merge feature-2 to main" `
--source-branch feature/myFeature-2 --target-branch main `
--repository myWebApp --open
```
Ein kritischer Fehler wird in der Produktion für das Release „feature-1“ mit dem aktiven Pull Request gemeldet. Um das Problem zu untersuchen, müssen Sie die Version des Codes debuggen, die derzeit in der Produktion bereitgestellt ist. Um das Problem zu untersuchen, erstellen Sie einen neuen fof-Branch, indem Sie das Tag „release_feature1“ verwenden:

myWebApp
```
git checkout -b fof/bug-1 release_feature1
```
Ausgabe:

Switched to a new branch, 'fof/bug-1'.

Ändern Sie die Datei „Program.cs“, indem Sie die gleiche Codezeile ändern, die im „feature-1“-Release geändert wurde:

public class Program
{
    // Editing the same line (file from feature-FOF branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

Stagen Sie Ihre Änderungen, und führen Sie den Commit lokal durch. Pushen Sie dann die Änderungen zum Remoterepository:

myWebApp
```
git add .
git commit -m "Adding FOF changes."
git push -u origin fof/bug-1
```
Ausgabe:

To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] fof/bug-1 - fof/bug-1 Branch fof/bug-1 set up to track remote branch fof/bug-1 from origin.
Unmittelbar nachdem ein Rollout der Änderungen in die Produktion erfolgt ist, markieren Sie den Branch „fof\bug-1“ mit dem Tag „release_bug-1“ und lösen dann einen Pull Request aus, um die Änderungen von „fof/bug-1“ wieder im Mainbranch zu mergen:
```
az repos pr create --title "Review Bug-1 before merging to main" --work-items 100 `
--description "#Merge Bug-1 to main" `
--source-branch fof/Bug-1 --target-branch main `
--repository myWebApp --open
```
Im Rahmen des Pull Requests wird der Branch gelöscht. Über das Tag können Sie jedoch weiterhin auf den gesamten Verlauf verweisen.

Nachdem der Fix für den kritischen Fehler aus dem Weg geräumt ist, wechseln Sie zur Überprüfung von Pull Request „feature-2“.

Auf der Seite der Branches ist deutlich zu erkennen, dass der Branch „feature/myFeature-2“ eine Änderung mehr und zwei Änderungen weniger als der Mainbranch aufweist:

Wenn Sie versuchen würden, den Pull Request zu genehmigen, würden Sie eine Fehlermeldung erhalten, die Sie über einen Konflikt beim Zusammenführen informiert:
Die Erweiterung zum Beheben von Git Pull Request-Zusammenführungskonflikten ermöglicht es, Zusammenführungskonflikte direkt im Browser zu beheben. Navigieren Sie zur Registerkarte „Konflikte“, und klicken Sie auf „Program.cs“, um die Zusammenführungskonflikte zu beheben:

In der Benutzeroberfläche können Sie die Quelle und das Ziel übernehmen, benutzerdefinierte Änderungen hinzufügen und den Merge überprüfen und übermitteln. Mit der Zusammenführung der Änderungen ist der Pull Request abgeschlossen.

An diesem Punkt können Sie eine Release-Verzweigung basierend auf der kritischen Fehlerkorrektur erstellen, die in der fof/bug-1 Verzweigung implementiert und in Master zusammengeführt wurde. Erstellen Sie mit dem Befehl „Git auschecken“ eine dedizierte Release-Verzweigung aus der Master-Verzweigung.

git checkout -b release/v1.1 main

Dieser Befehl erstellt eine neue Verzweigung namens release/v1.1 basierend auf der Master-Verzweigung.

Da wichtige Meilensteine während des Veröffentlichungsprozesses erreicht werden, markieren Sie Veröffentlichungen in der Release-Verzweigung mithilfe von Git-Tags. Tags dienen als Markierungen, um bestimmte Versionen der Software zu kennzeichnen.

git tag -a v1.1 -m "Release version 1.1"

Mit diesem Befehl wird ein Tag namens v1.1 erstellt, um die Version 1.1 in der Release-Verzweigung zu kennzeichnen.

Funktionsweise

Wir haben erfahren, wie das Git-Verzweigungsmodell Ihnen die Flexibilität bietet, parallel an Features zu arbeiten, indem Sie für jedes Feature einen Branch erstellen.

Mit dem Pull Request-Workflow können Sie Codeänderungen mithilfe der Branchrichtlinien überprüfen.

Git-Tags sind eine hervorragende Möglichkeit, Meilensteine aufzuzeichnen, z. B. die Version des freigegebenen Codes. Tags bieten Ihnen die Möglichkeit, Branches aus Tags zu erstellen.

Wir haben einen Branch aus einem früheren Releasetag erstellt, um einen kritischen Fehler in der Produktion zu beheben.

Die Ansicht „Branches“ im Webportal erleichtert die Identifizierung von Branches vor dem Mainbranch. Außerdem erzwingt sie einen Zusammenführungskonflikt, wenn aktive Pull Requests versuchen, in den Mainbranch zusammenzuführen, ohne die Zusammenführungskonflikte zu beheben.

Mit einem schlanken Branchmodell können Sie kurzlebige Branches erstellen und qualitative Änderungen schneller in die Produktionsumgebung pushen.

Weiter

Vorbereitung

Vorgehensweise

Funktionsweise

Feedback