MyFlow: Ein Git-Workflow für DevOps-Teams - Teil 1

Welcher ist der beste Git-Workflow für DevOps-Teams? Der beliebteste Arbeitsablauf für Git ist immer noch Git-Flow. Ich habe vor einiger Zeit mit einem Freund eine Umfrage auf Twitch durchgeführt und immer noch über 50% der Zuschauer gaben an, dass sie diesen Workflow verwenden. Und das ist seltsam, denn selbst Vincent Driessen, der Autor des ursprünglichen Beitrags über git-flow, schrieb im März 2020 in dem Beitrag, dass git-flow nicht der beste Workflow für Cloud-Dienste, Apps oder Webanwendungen ist. Warum ist es also immer noch so beliebt? Ich denke, dafür gibt es drei Gründe:

1. Es ist sehr detailliert, spezifisch und bietet eine Anleitung für Leute, die neu in Git sind.
2. Es hat einen tollen Namen, den man sich gut merken kann.
3. Es hat eine gute Visualisierung

Und was ist das Problem mit GitHub Flow? Nun, der Name klingt zu sehr nach GitFlow und die Beschreibung des Workflows ist nicht sehr präzise. Wie stellen Sie bereit? Was machen Sie mit langlebigen Funktionszweigen? Wie können Sie verschiedene Versionen für verschiedene Kunden unterstützen?

Ich denke, was wir brauchen, ist ein guter neuer Workflow mit einem guten Namen und einer schönen Grafik! Darf ich Ihnen vorstellen...

Der beste Git-Workflow für DevOps-Teams: MyFlow

MyFlow ist ein leichtgewichtiger, trunk-basierter Workflow, der auf Pull-Requests basiert. Das ist keine neue Erfindung! Viele Teams arbeiten bereits auf diese Weise. Es ist ein sehr natürlicher Weg zum Verzweigen und Zusammenführen, wenn Sie sich auf die Zusammenarbeit mit Pull-Requests konzentrieren. Ich versuche nur, ihr einen Namen zu geben und einige Erklärungen für Ingenieure hinzuzufügen, die neu in Git sind. Hier ist ein Überblick:

Dies ist Teil 1 einer Reihe von Beiträgen, in denen MyFlow beschrieben wird: eine Sammlung von Best Practices, wie Sie ein erfolgreiches Verzweigungsmodell für GitHub einrichten können.

Teil 1 behandelt den Hauptzweig und die Arbeit mit privaten Themenzweigen. In Teil 2 erkläre ich Versionszweige und semantische Versionierung. In Teil 3 zeige ich Ihnen, wie Sie Teile des Arbeitsablaufs mit Git-Aliasen automatisieren können.

Die Hauptniederlassung

MyFlow ist trunk-basiert - das bedeutet, dass es nur einen Hauptzweig namens main gibt. Der Zweig sollte sich immer in einem sauberen Zustand befinden, in dem jederzeit eine neue Version erstellt werden kann. Deshalb sollten Sie Ihren Zweig main mit einer Zweigschutzregel schützen. Eine gute Zweigschutzregel würde Folgendes beinhalten:

• Verlangen Sie mindestens zwei Pull-Reviews vor dem Zusammenführen.
• Veraltete Pull Request-Genehmigungen verwerfen, wenn neue Commits gepusht werden.
• Verlangen Sie eine Überprüfung durch die Codeverantwortlichen.
• Verlangen Sie, dass vor dem Zusammenführen Statusprüfungen durchgeführt werden, die Ihren CI-Build, die Testausführung, die Codeanalyse und die Linters umfassen.
• Beziehen Sie die Administratoren in die Einschränkungen ein.
• Erlaube Kraft schiebt.

Je mehr Sie den Workflow automatisieren, der durch Ihren Pull Request ausgelöst wird, desto wahrscheinlicher ist es, dass Sie Ihren Zweig in einem sauberen Zustand halten können.

Alle anderen Zweige werden immer von main verzweigt. Da dies Ihr Standardzweig ist, müssen Sie nie einen Quellzweig angeben, wenn Sie neue Zweige erstellen. Das vereinfacht die Dinge und beseitigt eine Fehlerquelle.

Private Themenzweige

Private Themenzweige können verwendet werden, um an neuen Funktionen, Dokumentationen, Fehlern, der Infrastruktur und allem anderen, was sich in Ihrem Repository befindet, zu arbeiten. Und: Sie sind privat - sie gehören also einem bestimmten Benutzer. Andere Teammitglieder können sich den Zweig ansehen, um ihn zu testen - aber sie dürfen keine direkten Änderungen an diesem Zweig vornehmen. Stattdessen müssen sie dem Autor des Pull-Requests über Vorschläge in Pull-Requests Änderungen vorschlagen.

Um anzuzeigen, dass die Zweige privat sind, empfehle ich eine Namenskonvention wie users/* oder private/*, die dies deutlich macht. Verwenden Sie keine Namenskonventionen wie features/* - sie implizieren, dass mehrere Entwickler an einer Funktion arbeiten können. Ich empfehle außerdem, die id des Problems oder Fehlers in den Namen aufzunehmen. Das macht es einfach, später in der Commit-Nachricht darauf zu verweisen. Eine gute Konvention wäre z.B.:

users/<username>/<id>_<topic>

Private Themenzweige sind Zweige mit geringer Komplexität. Wenn Sie an einer komplexeren Funktion arbeiten, sollten Sie Ihre Änderungen zumindest wieder in den Hauptzweig einbringen und den Themenzweig einmal am Tag mit Hilfe von Funktionsflags (auch Funktions-Toggles genannt) löschen. Wenn es sich um einfache Änderungen handelt, die leicht wieder in den Hauptzweig übernommen werden können, können Sie den Zweig länger offen lassen. Die Zweige sind von geringer Komplexität und nicht von kurzer Dauer.

Arbeit an einem neuen Thema beginnen

Um mit der Arbeit an einem neuen Thema zu beginnen, führen Sie also drei Schritte aus:

1. Einen neuen Zweig erstellen
2. Commit und eine kleine Änderung anstoßen
3. Erstellen Sie eine Pull-Anfrage im Entwurfsmodus

Einen neuen Zweig erstellen

Um einen neuen Zweig lokal zu erstellen, verwenden Sie git switch:

 $ git switch -c <branch-name>

Zum Beispiel:

$ git switch -c users/kaufm/42_my-new-feature main
> Switched to a new branch 'users/kaufm/42_my-new-feature'

Commit und eine kleine Änderung anstoßen

Erstellen Sie Ihre ersten Änderungen und übertragen Sie diese auf den Server. Es spielt keine Rolle, was Sie ändern - Sie können einfach eine leere Zeile in eine Datei einfügen. Sie können die Änderung später sowieso überschreiben. Add, commit, und push die Änderung:

 $ git add .
 $ git commit
 $ git push --set-upstream origin <branch-name>

Zum Beispiel:

 $ git add .
 $ git commit
 $ git push --set-upstream origin users/kaufm/42_my-new-feature

Beachten Sie, dass ich den Parameter -m in git commit nicht angegeben habe, um die Commit-Nachricht festzulegen. Ich ziehe es vor, dass mein Standard-Editor COMMIT_EDITMSG öffnet, so dass ich die Commit-Nachricht dort bearbeiten kann. Auf diese Weise kann ich die Dateien mit den Änderungen sehen und habe eine visuelle Hilfe, wo die Zeilen umgebrochen werden sollen. Stellen Sie sicher, dass Sie Ihren Editor richtig eingestellt haben, wenn Sie dies tun möchten. Wenn Sie z.B. Visual Studio Code bevorzugen, können Sie es mit als Standardeditor einstellen: $ git config --global core.editor "code --wait"

Erstellen Sie eine Pull-Anfrage im Entwurfsmodus

Jetzt erstellen Sie eine Pull-Anfrage im Entwurfsmodus. Auf diese Weise weiß das Team, dass Sie an diesem speziellen Thema arbeiten. Ein kurzer Blick auf die Liste der offenen Pull-Anfragen sollte Ihnen einen guten Überblick über die Themen geben, an denen das Team gerade arbeitet.

Note that I use the GitHub CLI to interact with pull requests as I find it easier to read and understand than to use screenshots of the web UI. You can do the same using the web UI.

$ gh pr create --fill --draft

Die Option --fill setzt automatisch den Titel und die Beschreibung des pr aus Ihrem Commit. Wenn Sie beim Übertragen Ihrer Änderungen das Argument weggelassen haben und in Ihrem Standard-Editor eine mehrzeilige Commit-Nachricht hinzugefügt haben, wird die erste Zeile der Titel der Pull-Anforderung sein und der Rest der Nachricht der Body. Sie können title (--title oder -t) und body (--body oder -b) auch direkt bei der Erstellung der Pull-Anfrage festlegen, anstatt die Option --fill zu verwenden.

Arbeiten Sie an Ihrem Thema

Sie können jetzt mit der Arbeit an Ihrem Thema beginnen. Und Sie können die volle Leistung von git nutzen. Wenn Sie z.B. Änderungen zu Ihrem vorherigen Commit hinzufügen möchten, können Sie dies mit der Option --amend tun:

$ git commit --amend

Oder wenn Sie die letzten drei Commits zu einem einzigen Commit zusammenfassen möchten:

$ git reset --soft HEAD~3
$ git commit

Wenn Sie alle Commits in der Verzweigung zu einem Commit zusammenführen möchten, können Sie den folgenden Befehl ausführen:

$ git reset --soft main
$ git commit

Wenn Sie die völlige Freiheit haben wollen, alle Ihre Commits neu anzuordnen und zu zerquetschen, können Sie interaktives Rebase verwenden:

$ git rebase -i main

Um die Änderungen auf den Server zu übertragen, verwenden Sie den folgenden Befehl:

$ git push origin +<branch>

In unserem Beispiel:

$ git push origin +users/kaufm/42_my-new-feature

Das Plus vor dem Namen der Verzweigung bewirkt, dass nur die betreffende Verzweigung gepusht wird. Wenn Sie nicht an der Historie Ihrer Zweige herumspielen wollen, können Sie einen normalen ohne Angabe des Ursprungs und des Zweignamens durchführen. Wenn Ihre Zweige gut geschützt sind und Sie wissen, was Sie tun, ist ein normaler Force Push möglicherweise praktischer:

$ git push -f

Falls Sie in diesem Stadium Hilfe oder Meinungen Ihrer Teamkollegen zu Ihrem Code benötigen, können Sie diese in den Kommentaren der Pull-Anfrage erwähnen. Wenn sie Änderungen vorschlagen möchten, verwenden sie die Vorschlagsfunktion in den Pull Request-Kommentaren. Auf diese Weise wenden Sie die Änderungen an und können sicherstellen, dass Sie vorher einen sauberen Zustand in Ihrem Repository haben.

Beenden Sie Ihr Thema

Sobald Sie das Gefühl haben, dass Ihre Arbeit fertig ist, ändern Sie den Status Ihrer Pull-Anfrage von Entwurf auf fertig und aktivieren die automatische Zusammenführung:

$ gh pr ready
$ gh pr merge --auto --delete-branch --rebase

Ich habe hier --rebase als Zusammenführungsmethode angegeben. Dies ist eine gute Merge-Strategie für kleine Teams, die eine gute und übersichtliche Commit-Historie erstellen möchten, die aber dennoch linear sein soll. Wenn Sie --squash oder --merge bevorzugen, passen Sie Ihre Merge-Strategie entsprechend an. Squash ist gut für größere Teams oder Teams, die es nicht gewohnt sind, sehr prägnante Commit-Nachrichten zu erstellen. Merge ist nur für kleine Teams mit nur kurzlebigen Zweigen geeignet, die ihre Zweige in der Historie sichtbar halten wollen.

Ihre Reviewer können in ihren Kommentaren immer noch Vorschläge machen, und Sie können weiter zusammenarbeiten. Aber sobald alle Genehmigungen und alle automatisierten Prüfungen abgeschlossen sind, wird die Pull-Anfrage automatisch zusammengeführt und die Verzweigung wird gelöscht. Die automatisierten Prüfungen laufen über den pull_request Trigger und können die Installation der Anwendung in einer isolierten Umgebung und die Durchführung aller möglichen Tests beinhalten.

Aufräumen

Wenn Ihr Pull Request zusammengeführt und der Zweig gelöscht wurde, bereinigen Sie Ihre lokale Umgebung:

$ git switch main
$ git pull --prune

Dies ändert Ihren aktuellen Zweig in main, zieht die Änderungen vom Server und löscht die lokalen Zweige, die auf dem Server gelöscht wurden.

Zusammenfassung

Der perfekte Git-Workflow für Ihr Team hängt von vielen Dingen ab:

• Die Anzahl der Entwickler, die an einem Produkt arbeiten
• Die Komplexität des Produkts
• Wenn Sie ein Monoreposystem verwenden oder mehrere Repos pro Produkt einsetzen
• Die Erfahrung mit Git, die Ihre Entwickler haben
• Ihr Git-Dienst (GitHub, GitLab, Bitbucket,...)
• Wie Sie Ihr Produkt veröffentlichen
• Und so weiter

Es gibt keine allgemeingültige Lösung. Aber Teams brauchen eine Art Anleitung, entweder wenn sie neu bei Git sind oder die Plattform wechseln. Oder wenn sie einen alten Arbeitsablauf haben, den sie an einen neuen Veröffentlichungsprozess oder ein neues Git-System anpassen müssen.

In diesem Beitrag habe ich Ihnen die Grundlagen von MyFlow gezeigt: eine Sammlung von Best Practices für die Arbeit in einem trunk-basierten Workflow mit Git (in diesem Fall GitHub). Im nächsten Teil werde ich auf Releases, Hotfixes und semantische Versionierung eingehen.