Heading

Gitflow Workflow ist ein Git-Workflow, der bei der kontinuierlichen Softwareentwicklung und der Implementierung von DevOps-Praktiken hilft. Er wurde erstmals von Vincent Driessen bei nvie veröffentlicht und populär gemacht. Der Gitflow Workflow definiert ein striktes Verzweigungsmodell, das sich an der Projektveröffentlichung orientiert. Dies bietet ein robustes Framework für die Verwaltung größerer Projekte.

Gitflow eignet sich ideal für Projekte, die einen geplanten Release-Zyklus haben und für die DevOps-Best-Practice der kontinuierlichen Bereitstellung. Dieser Workflow fügt keine neuen Konzepte oder Befehle hinzu, die über das hinausgehen, was für den Feature Branch Workflow erforderlich ist. Stattdessen weist er den verschiedenen Zweigen ganz bestimmte Rollen zu und definiert, wie und wann sie interagieren sollen. Zusätzlich zu den feature Zweigen verwendet er einzelne Zweige für die Vorbereitung, Pflege und Aufzeichnung von Releases. Natürlich können Sie auch alle Vorteile des Feature-Branch-Workflows nutzen: Pull-Requests, isolierte Experimente und eine effizientere Zusammenarbeit.

Einstieg

Gitflow ist eigentlich nur eine abstrakte Idee eines Git-Workflows. Das bedeutet, dass es vorgibt, welche Art von Zweigen einzurichten sind und wie sie zusammengeführt werden sollen. Auf die Zwecke der Zweige werden wir weiter unten eingehen. Das git-flow-Toolset ist ein tatsächliches Befehlszeilenwerkzeug, das einen Installationsprozess hat. Der Installationsvorgang für git-flow ist unkompliziert. Pakete für git-flow sind auf mehreren Betriebssystemen verfügbar. Auf OSX-Systemen können Sie brew install git-flow ausführen. Auf Windows müssen Sie git-flow herunterladen und installieren. Nach der Installation von git-flow können Sie es in Ihrem Projekt durch Ausführen von git flow init verwenden. Git-flow ist ein Wrapper um Git herum. Der git flow init-Befehl ist eine Erweiterung des Standard-git init-Befehls und ändert nichts an Ihrem Repository, außer dass es Zweige für Sie erstellt.

Wie es funktioniert

Entwicklungs- und Master-Zweige

Anstatt eines einzelnen master-Zweiges verwendet dieser Arbeitsablauf zwei Zweige, um die Geschichte des Projekts aufzuzeichnen. Der master-Zweig speichert die offizielle Release-Historie, und der develop-Zweig dient als Integrationszweig für Features. Es ist auch praktisch, alle Commits im master Zweig mit einer Versionsnummer zu versehen.

Der erste Schritt ist, den Standard master mit einem develop Zweig zu ergänzen. Ein einfacher Weg, dies zu tun, ist, dass ein Entwickler lokal einen leeren develop-Zweig erstellt und diesen auf den Server schiebt:

git branch develop
git push -u origin develop

Dieser Zweig wird die komplette Historie des Projekts enthalten, während master eine gekürzte Version enthalten wird. Andere Entwickler sollten nun das zentrale Repository klonen und einen Verfolgungszweig für develop.

Wenn Sie die Erweiterungsbibliothek git-flow verwenden, wird durch das Ausführen von git flow init auf einem bestehenden Repository der develop-Zweig erstellt:

$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: 
Branch name for "next release" development: 
How to name your supporting branch prefixes?
Feature branches? 
Release branches? 
Hotfix branches? 
Support branches? 
Version tag prefix? 
$ git branch
* develop
master

Funktionszweige

Jedes neue Feature sollte sich in einem eigenen Zweig befinden, der zur Sicherung/Zusammenarbeit in das zentrale Repository geschoben werden kann. Aber anstatt von master abzuzweigen, verwenden feature-Zweige develop als übergeordneten Zweig. Wenn ein Feature fertiggestellt ist, wird es wieder in develop zusammengeführt. Features sollten niemals direkt mit master interagieren.

Beachten Sie, dass feature-Zweige in Kombination mit dem develop-Zweig im Grunde genommen der Feature Branch Workflow ist. Aber der Gitflow-Workflow hört damit nicht auf.

Feature Zweige werden in der Regel aus dem neuesten develop Zweig erstellt.

Erstellen eines Feature-Zweiges

Ohne die Git-Flow-Erweiterung:

git checkout develop
git checkout -b feature_branch

Bei Verwendung der Git-Flow-Erweiterung:

git flow feature start feature_branch

Weiterarbeiten und Git wie gewohnt verwenden.

Fertigstellen eines Funktionszweigs

Wenn Sie mit der Entwicklungsarbeit an der Funktion fertig sind, ist der nächste Schritt, das feature_branch in develop zusammenzuführen.

Ohne die Git-Flow-Erweiterungen:

git checkout develop
git merge feature_branch

Unter Verwendung der Git-Flow-Erweiterungen:

git flow feature finish feature_branch

Veröffentlichungszweige

Wenn develop genügend Funktionen für eine Veröffentlichung erworben hat (oder ein vorgegebenes Veröffentlichungsdatum naht), faken Sie einen release-Zweig von develop. Das Erstellen dieses Zweiges startet den nächsten Release-Zyklus, so dass keine neuen Funktionen nach diesem Punkt hinzugefügt werden können – nur Fehlerbehebungen, Dokumentationserstellung und andere release-orientierte Aufgaben sollten in diesen Zweig gehen. Sobald es fertig ist, wird der release Zweig in master zusammengeführt und mit einer Versionsnummer versehen. Außerdem sollte es wieder in develop zusammengeführt werden, das sich seit der Freigabe weiterentwickelt hat.

Die Verwendung eines dedizierten Zweigs zur Vorbereitung von Freigaben ermöglicht es einem Team, die aktuelle Freigabe zu polieren, während ein anderes Team weiter an Funktionen für die nächste Freigabe arbeitet. Es schafft auch klar definierte Phasen der Entwicklung (z.B. ist es einfach zu sagen: „Diese Woche bereiten wir die Version 4.0 vor“, und es tatsächlich in der Struktur des Repositorys zu sehen).

Das Erstellen von release Zweigen ist eine weitere einfache Verzweigungsoperation. Wie feature-Zweige basieren auch release-Zweige auf dem develop-Zweig. Ein neuer release-Zweig kann mit den folgenden Methoden erstellt werden.

Ohne die Git-Flow-Erweiterungen:

git checkout develop
git checkout -b release/0.1.0

Wenn Sie die Git-Flow-Erweiterungen verwenden:

$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'

Wenn die Veröffentlichung fertig ist, wird sie in master und develop zusammengeführt, dann wird der release-Zweig gelöscht. Es ist wichtig, wieder in den develop-Zweig einzubinden, da dem release-Zweig möglicherweise kritische Updates hinzugefügt wurden und diese für neue Funktionen zugänglich sein müssen. Wenn Ihre Organisation Wert auf Code-Review legt, wäre dies ein idealer Ort für einen Pull-Request.

Um einen release-Zweig abzuschließen, verwenden Sie die folgenden Methoden:

Ohne die Git-Flow-Erweiterungen:

git checkout master 
git merge release/0.1.0

Oder mit der Git-Flow-Erweiterung:

git flow release finish '0.1.0'

Hotfix-Zweige

Wartungs- oder "hotfix”Zweige werden verwendet, um Produktionsversionen schnell zu patchen. Hotfix-Zweige sind ähnlich wie release-Zweige und feature-Zweige, außer dass sie auf master anstelle von develop basieren. Dies ist der einzige Zweig, der direkt von master abzweigen sollte. Sobald die Korrektur fertig ist, sollte sie sowohl in master als auch in develop (oder in den aktuellen release Zweig) eingebunden werden, und master sollte mit einer aktualisierten Versionsnummer versehen werden.

Einen eigenen Entwicklungszweig für Fehlerbehebungen zu haben, lässt Ihr Team Probleme angehen, ohne den Rest des Arbeitsablaufs zu unterbrechen oder auf den nächsten Release-Zyklus zu warten. Sie können sich Wartungszweige als ad hoc release Zweige vorstellen, die direkt mit master arbeiten. Ein hotfix-Zweig kann mit den folgenden Methoden erstellt werden:

Ohne die Git-Flow-Erweiterungen:

git checkout master
git checkout -b hotfix_branch

Bei Verwendung der Git-Flow-Erweiterungen:

$ git flow hotfix start hotfix_branch

Ähnlich dem Beenden eines release-Zweiges, wird ein hotfix-Zweig sowohl in master als auch develop.

git checkout master
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch

$ git flow hotfix finish hotfix_branch

Beispiel

Ein komplettes Beispiel, das den Ablauf eines Feature-Branches demonstriert, ist wie folgt. Angenommen, wir haben ein Repo-Setup mit einem master Branch.

git checkout master
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout master
git merge develop
git branch -d feature_branch

Zusätzlich zu dem feature und release Fluss, ist ein hotfix Beispiel wie folgt:

git checkout master
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout master
git merge hotfix_branch

Zusammenfassung

Hier haben wir den Gitflow-Workflow besprochen. Gitflow ist eine von vielen Arten von Git-Workflows, die Sie und Ihr Team nutzen können.

Ein paar wichtige Erkenntnisse über Gitflow sind:

• Der Workflow eignet sich hervorragend für einen Release-basierten Software-Workflow.
• Gitflow bietet einen eigenen Kanal für Hotfixes zur Produktion.

Der Gesamtablauf von Gitflow ist:

1. Ein develop-Zweig wird von master
2. Ein release-Zweig wird von develop
3. Feature-Zweige werden aus develop
4. Wenn ein feature-Zweig vollständig ist, wird er in den develop-Zweig zusammengeführt
5. Wenn der release-Zweig fertig ist, wird er in develop und master zusammengeführt
6. Wenn ein Problem in master entdeckt wird, wird ein hotfix Zweig von master
7. Wenn der hotfix fertig ist, wird er sowohl mit develop als auch mit master zusammengeführt

Nächste, erfahren Sie mehr über den Forking Workflow oder besuchen Sie unsere Workflow-Vergleichsseite.