Git-flow-Workflow

 

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

Gitflow 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 genau festgelegt, wann und wie die Interaktion aussehen 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-Requests, isolierte Tests und eine effizientere Zusammenarbeit.

Neben dem abstrakten Konzept des Gitflow-Workflows ist auch noch ein Git-flow Toolset verfügbar, das in Git integrierbar ist und spezialisierte Erweiterungstools für die Befehlszeile bereitstellt.

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 jetzt Branches für dich erstellt werden können.

Wie es funktioniert

Gitflow-Workflow – Verlaufs-Branches

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 und der develop-Branch dient als Integrations-Branch für Features. Es ist zudem üblich, alle Commits im master-Branch mit einer Versionsnummer zu taggen.

Der erste Schritt ist, den obligatorischen Master- mit einem develop-Branch zu ergänzen. Entwickler können das ganz einfach tun, indem sie einen leeren develop-Branch lokal erstellen und ihn zum Server pushen:

git branch develop
git push -u origin develop

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

Wenn du die Gitflow-Erweiterungsbibliothek verwendest, wird beim Ausführen von git flow init in einem bestehenden Repository der develop Branch erstellt:

$ git flow init
Leeres Git-Repository in ~/project/.git/ initialisiert
Noch keine Branches vorhanden. Basis-Branches müssen jetzt erstellt werden.
Branch-Name für Produktions-Releases: [master]
Branch-Name für die Entwicklungsarbeiten für den nächsten Release: [develop]
Wie sollen die Präfixe für Support Branches benannt werden?
Feature Branches? [feature/]
Release Branches? [release/]
Hotfix Branches? [hotfix/]
Support Branches? [support/]
Präfix des Versions-Tags? []
$ git branch
* develop
 master

Feature Branches

Jedes neue Feature sollte sich auf seinem eigenen Branch befinden, der zu Sicherungs-/Zusammenarbeitszwecken zum zentralen Repository gepusht werden kann. Doch anstatt 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 Branch interagieren.

Gitflow-Workflow – Feature Branches

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

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

Einen Feature Branch erstellen

Ohne die Gitflow-Erweiterungen:

git checkout develop
git checkout -b feature_branch

Mit der Gitflow-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 Gitflow-Erweiterungen:

git checkout develop
git merge feature_branch

Mit der Gitflow-Erweiterung:

git flow feature finish feature_branch

Release-Branches

Gitflow-Workflow: Release-Branches

Wenn 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 geforkt. 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 es 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 folgenden Methoden erstellt werden.

Ohne die Gitflow-Erweiterungen:

git checkout develop
git checkout -b release/0.1.0

Mit der Gitflow-Erweiterung:

$ git flow release start 0.1.0
Wechsel zu einem neuen Branch namens "release/0.1.0"

Ist der Release bereit zur Auslieferung, wird er 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 eventuell kritische Updates enthalten kann, auf die neue Features Zugriff haben müssen. Wenn deine Organisation Code-Reviews nutzt, ist hier ein sehr guter Zeitpunkt für einen Pull-Request.

Du beendest einen release Branch mit den folgenden Methoden:

Ohne die Gitflow-Erweiterungen:

git checkout develop
git merge release/0.1.0

Oder mit der Git-flow-Erweiterung:

git checkout master
git checkout merge release/0.1.0
git flow release finish '0.1.0'

Hotfix Branches

Gitflow-Workflow – 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 geforkt werden sollte. Sobald der Fix abgeschlossen wurde, 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 solche 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 Gitflow-Erweiterungen:

git checkout master
git checkout -b hotfix_branch

Mit der Gitflow-Erweiterung: 

$ git flow hotfix start hotfix_branch

Ähnlich wie beim Abschluss 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

Summary

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

Wichtige Punkte zum Gitflow:

  • Der Workflow eignet sich hervorragend für release-basierte Software-Workflows.
  • Gitflow bietet einen eigenen Kanal für Hotfixes bis zur Produktion.
     

Der allgemeine Git-flow-Ablauf sieht so aus:

  1. Ein develop-Branch wird auf Basis des Master Branches erstellt.
  2. Ein release Branch wird vom develop Branch erstellt.
  3. Ein feature Branch wird ebenfalls vom develop Branch erstellt.
  4. Wenn ein feature fertig ist, wird es in den develop-Branch gemergt.
  5. Ist der release Branch abgeschlossen, wird er in den develop Branch und den master Branch gemergt.
  6. Taucht ein Problem im Master auf, wird ein Hotfix Branch auf Basis des Master erstellt.
  7. Sobald der hotfix abgeschlossen ist, wird er in den develop Branch und den master Branch gemergt.

Fahre nun fort mit dem Forking-Workflow oder sieh dir unseren Workflow-Vergleich an.

Du möchtest mit Git arbeiten?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen