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 desmaster
erstellt. - Ein
release
-Branch wird auf Basis desdevelop
-Branch erstellt. feature
-Branches werden auf der Basis desdevelop
-Branch erstellt.- Wenn ein
feature
fertig ist, wird es in dendevelop
-Branch gemergt. - Wenn der
release
-Branch abgeschlossen ist, wird er in dendevelop
-Branch und in denmaster
gemergt. - Wird ein Problem im
master
erkannt, wird einhotfix
-Branch auf Basis desmaster
erstellt. - Sobald der
hotfix
abgeschlossen ist, wird er in dendevelop
-Branch und in denmaster
gemergt.
Du kannst mit dem Forking-Workflow fortfahren oder dir unsere Seite mit dem Workflow-Vergleich ansehen.