Git-flow-Workflow

Der Git-flow-Workflow ist ein Git-Workflow, der von Vincent Driessen auf nvie veröffentlicht und bekannt gemacht wurde. Der Git-flow-Workflow definiert ein strenges Branching-Modell, das um den Release des Projekts konzipiert wurde. Dies bietet einen robusten Rahmen für das Management größerer Projekte.

Git-flow ist hervorragend für Projekte mit einem Release-Zyklus nach Zeitplan geeignet. Mit diesem Workflow werden keine neuen Konzepte oder Befehle hinzugefügt, die nicht auch für den Feature-Branch-Workflow erforderlich sind. Stattdessen werden verschiedenen Branches sehr spezifische Rollen zugewiesen, und es wird genau festgelegt, wann und wie die Interaktion erfolgen soll. Zusätzlich zu feature-Branches werden einzelne Branches zum Vorbereiten, Warten und Erfassen von Releases verwendet. Dabei kannst du natürlich auch alle Vorteile von Feature-Branch-Workflows nutzen: Pull-Anfragen, isolierte Tests und eine effizientere Zusammenarbeit.

Erste Schritte

Git-flow ist nur eine abstrakte Vorstellung eines Git-Workflows. Dabei wird lediglich vorgegeben, welche Art von Branches einzurichten und wie sie zu mergen sind. Welchen Zweck die Branches erfüllen, sehen wir später. Die Git-flow-Tools sind echte Befehlszeilentools, die eine Installation voraussetzen. Der Installationsprozess für Git-flow ist ganz einfach. Git-flow-Pakete sind für mehrere Betriebssysteme verfügbar. Auf OS X-Systemen führst du einfach brew install git-flow aus. Unter Windows musst du Git-flow herunterladen und installieren. Nach der Installation kannst du Git-flow mit dem Befehl git flow init in deinem Projekt nutzen. Git-flow ist eine Art Umhüllung für Git. Der Befehl git flow init ist eine Erweiterung des Standardbefehls git init. In deinem Repository ändert sich dabei nichts, außer dass Branches für dich erstellt werden.

Wie es funktioniert

Develop Branches und Master Branches

Statt eines einzelnen master-Branch sieht dieser Workflow zwei Branches vor, um den Verlauf des Projekts aufzuzeichnen. Der master-Branch enthält den offiziellen Release-Verlauf, während der develop-Branch als Integrations-Branch für Features dient. Es ist zudem üblich, alle Commits im master-Branch mit einer Versionsnummer zu taggen.

Im ersten Schritt sollte der obligatorische master-Branch um einen develop-Branch ergänzt werden. Dazu können Entwickler einfach lokal einen leeren develop-Branch erstellen und ihn zum Server pushen:

git branch develop
git push -u origin develop

Dieser Branch enthält dann den kompletten Versionsverlauf des Projekts, während der master eine verkürzte Version enthält. Andere Entwickler sollten das zentrale Repository nun klonen und einen Tracking-Branch für develop erstellen.

Wenn du die Git-flow-Erweiterungsbibliothek verwendest, wird beim Ausführen von git flow init in einem bestehenden Repository der develop-Branch 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: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

$ git branch
* develop
 master

Feature Branches

Jedes neue Feature sollte sich in einem eigenen Branch befinden, der zu Sicherungs-/Zusammenarbeitszwecken zum zentralen Repository gepusht werden kann. Doch statt Branches auf Basis des master zu erstellen, nutzen Feature-Branches den develop-Branch als übergeordneten Branch. Wenn ein Feature fertig ist, wird es zurück in den develop-Branch gemergt. Features sollten niemals direkt mit dem master interagieren.

Beachte, dass die Kombination von feature-Branches mit dem develop-Branch eigentlich dem Feature-Branch-Workflow entspricht. Der Git-flow-Workflow geht jedoch darüber hinaus.

feature-Branches werden für gewöhnlich auf Basis des aktuellen develop-Branch erstellt.

Einen Feature Branch erstellen

Ohne die Git-flow-Erweiterungen:

git checkout develop
git checkout -b feature_branch

Mit der Git-flow-Erweiterung:

git flow feature start feature_branch

Setze deine Arbeit fort und nutze Git wie gewohnt.

Einen Feature Branch abschließen

Wenn die Entwicklungsarbeiten am Feature abgeschlossen sind, muss als Nächstes der feature_branch in den develop-Branch gemergt werden.

Ohne die Git-flow-Erweiterungen:

git checkout develop
git merge feature_branch

Mit der Git-flow-Erweiterung:

git flow feature finish feature_branch

Release-Branches

Sobald der develop-Branch genügend Features für ein Release enthält (oder ein vordefinierter Release-Termin ansteht), wird vom develop-Branch ein release-Branch abgespalten. Damit beginnt der neue Release-Zyklus. In diesem Branch sollten ab diesem Punkt keine neuen Features mehr hinzugefügt werden, sondern nur Bugfixes und ähnliche Release-orientierte Änderungen. Ist er zur Auslieferung bereit, wird der release-Branch in den master gemergt und mit einer Versionsnummer getaggt. Zusätzlich sollte er zurück in den develop-Branch gemergt werden, der sich seit Initiierung des Release weiterentwickelt haben könnte.

Werden Releases in dedizierten Branches vorbereitet, ist paralleles Arbeiten möglich: Eines eurer Teams kann dem aktuellen Release den letzten Schliff geben, während ein anderes Team sich weiter um die Features des nächsten Release kümmert. Außerdem lassen sich auf diese Weise klar abgegrenzte Entwicklungsphasen definieren. Wenn ihr euch entscheidet, in einer Woche an Version 4.0 zu arbeiten, kann die Struktur eures Repositorys diese Entscheidung abbilden.

Das Erstellen von release-Branches ist ebenfalls ein unkomplizierter Branching-Vorgang. Wie die feature-Branches basieren release-Branches auf dem develop-Branch. Ein neuer release-Branch kann mit den nachfolgend genannten Methoden erstellt werden.

Ohne die Git-flow-Erweiterungen:

git checkout develop
git checkout -b release/0.1.0

Mit der Git-flow-Erweiterung:

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

Ist das Release bereit zur Auslieferung, wird es in den master-Branch und den develop-Branch gemergt. Anschließend wird der release-Branch gelöscht. Es ist wichtig, zurück in den develop-Branch zu mergen, da der release-Branch unter Umständen kritische Updates enthält, auf die neue Features Zugriff haben müssen. Wenn deine Organisation Code-Reviews nutzt, ist hier ein sehr guter Zeitpunkt für eine Pull-Anfrage.

Du kannst einen release-Branch mit den folgenden Methoden abschließen:

Ohne die Git-flow-Erweiterungen:

git checkout master
git merge release/0.1.0

Mit der Git-flow-Erweiterung:

git flow release finish '0.1.0'

Hotfix Branches

Maintenance-Branches bzw. hotfix-Branches eignen sich für schnelle Patches von Produktions-Releases. hotfix-Branches sind release-Branches und feature-Branches sehr ähnlich, basieren jedoch auf dem master statt auf dem develop-Branch. Dies ist der einzige Branch, der direkt vom master abgespalten werden sollte. Sobald der Fix abgeschlossen ist, sollte er sowohl in den master als auch in den develop-Branch (oder den aktuellen release-Branch) gemergt werden. Der master sollte außerdem mit einer aktualisierten Versionsnummer getaggt werden.

Durch eine dedizierte Entwicklungslinie für Bugfixes kann ein Team Probleme beheben, ohne den Rest des Workflows zu unterbrechen oder auf den nächsten Release-Zyklus warten zu müssen. Maintenance-Branches sind sozusagen Ad-hoc-release-Branches, die direkt mit dem master interagieren. Einen hotfix-Branch kannst du mithilfe folgender Methoden erstellen:

Ohne die Git-flow-Erweiterungen:

git checkout master
git checkout -b hotfix_branch

Mit der Git-flow-Erweiterung:

$ git flow hotfix start hotfix_branch

Ähnlich wie beim Abschließen eines release-Branch wird ein hotfix-Branch sowohl in den master als auch in den develop-Branch gemergt.

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

Im Folgenden siehst du ein vollständiges Beispiel für einen Feature-Branch-Workflow. Nehmen wir an, wir haben ein Repository mit einem master-Branch eingerichtet.

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 zum feature-Workflow und release-Workflow sieht ein hotfix-Beispiel folgendermaßen aus:

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

Wir haben hier den Git-flow-Workflow besprochen. Git-flow ist eine der vielen Varianten des Git-Workflows, die du mit deinem Team nutzen kannst.

Wichtige Punkte zum Git-flow:

Der Workflow eignet sich hervorragend für Release-basierte Software-Workflows.
Git-flow bietet einen eigenen Kanal für Hotfixes bis zur Produktion.

Der allgemeine Git-flow-Ablauf sieht so aus:

Ein develop-Branch wird auf Basis des master erstellt.
Ein release-Branch wird auf Basis des develop-Branch erstellt.
feature-Branches werden auf der Basis des develop-Branch erstellt.
Wenn ein feature fertig ist, wird es in den develop-Branch gemergt.
Wenn der release-Branch abgeschlossen ist, wird er in den develop-Branch und in den master gemergt.
Wird ein Problem im master erkannt, wird ein hotfix-Branch auf Basis des master erstellt.
Sobald der hotfix abgeschlossen ist, wird er in den develop-Branch und in den master gemergt.