Der Gitflow-Workflow definiert ein striktes Branching-Modell für Entwicklungsteams, das auf die nahtlose Auslieferung von Releases in großen Software-Projekten abzielt. Nachdem der vorangehende Artikel die Grundlagen dieses Prozesses umrissen hat, zeigt das folgende Beispiel eines einzelnen Release-Zyklus' nun, wie ein Team konkret nach diesem Workflow arbeiten kann.

Einen Develop-Branch erzeugen

Ausgehend von der Annahme, dass bereits ein zentrales Repository aufgesetzt wurde, besteht der erste Schritt darin, den obligatorischen Master- um einen Develop-Branch zu ergänzen. Hier erzeugt der Entwickler einen leeren Develop-Branch lokal und pusht in zum Server:

git branch develop
git push -u origin develop

Dieser Branch wird die komplette Versions-Historie des Projekts enthalten, während der Master eine verkürzte History abbildet. Andere Entwickler sollten das zentrale Repository nun klonen und einen Tracking-Branch für den Develop-Branch erzeugen:

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

Nun hat jeder eine lokale Kopie der historischen Branches aufgesetzt.

Entwickler A und B beginnen neue Features

Das Beispiel beginnt mit Entwickler A und Entwickler B, die an separaten Features arbeiten. Beide benötigen separate Branches, die statt auf dem Master- auf dem Develop-Branch basieren:

git checkout -b some-feature develop

Beide fügen den Feature-Branches Commits nach dem gewohnte Vorgehen hinzu: Edit, stage, commit.

git status
git add
git commit

Entwickler A stellt sein Feature fertig

Nach mehreren Commits ist Entwickler A der Meinung, dass das Feature fertig ist. Falls sein Team mit Pull-Requests arbeitet, wäre dies ein guter Zeitpunkt, einen aufzusetzen und darum zu bitten, das Feature in den Develop-Branch zu mergen. Andernfalls kann er es wie folgt in seinen lokalen Develop-Branch mergen und in das zentrale Repository pushen:

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

Der erste Befehl stellt sicher, dass der Develop-Branch aktuell ist, bevor versucht wird, das Feature in diesen zu mergen. Konflikte werden auf die gleiche Weise wie beim zentralisierten Workflow aufgelöst.

Entwickler A beginnt mit der Vorbereitung eines Releases

Während Entwickler B nach wie vor an seinem Feature arbeitet, beginnt Entwickler A damit, das erste offizielle Release des Projekts vorzubereiten. Wie bei der Feature-Entwicklung nutzt er einen neuen Branch, um die Release-Vorbereitungen abzukapseln. In diesem Schritt wird auch die Versionsnummer des Releases vergeben:

git checkout -b release-0.1 develop

Dieser Branch ist dazu da, das Release feinzuschleifen, alles zu testen, die Dokumentation zu aktualisieren und alle weiteren Vorbereitungen für die anstehende Auslieferung zu treffen.

Sobald Entwickler A den Branch erstellt und ihn in das zentrale Repository pusht, ist er für Features geschlossen. Jede Funktion, die nicht bereits im Develop-Branch ist, wird für den nächsten Release-Zyklus aufgeschoben.

Entwickler A stellt das Release fertig

Ist das Release bereit zur Auslieferung, mergt Entwickler A es in den Master- und in den Develop-Branch und löscht anschließend den Release-Branch. Es ist wichtig, zurück in den Develop-Branch zu mergen, da der Release-Branch eventuell kritische Updates enthält, die für neue Features vorhanden sein müssen. Und auch hier gilt: Wenn das Team von Entwickler A Code-Reviews nutzt, ist hier ein sehr guter Zeitpunkt für einen Pull-Request.

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

Release-Branches fungieren als Puffer zwischen der Feature-Entwicklung (Develop-Branch) und öffentlichen Releases (Master-Branch). Wann immer etwas in den Master-Branch gemergt wird, sollte der Commit getaggt werden, um ihn leicht referenzieren zu können:

git tag -a 0.1 -m "initial public release" master
git push --tags

Git bringt diverse Hooks mit. Das sind Skripte, die ausgeführt werden, wann immer ein bestimmtes Ereignis im Repository passiert. Diese Hooks können konfiguriert werden, dass automatisch ein öffentliches Release gebaut wird, wann immer der Master-Branch in das zentrale Repository oder wann immer ein Tag gepusht wird.

Endnutzer entdeckt einen Bug

Nach der Auslieferung des Releases macht sich Entwickler A daran, mit Entwickler B Features für das nächste Release zu bauen – bis ein Endnutzer ein Ticket anlegt, in dem er einen Bug im aktuellen Produktiv-Release berichtet. Um diesen Bug zu beseitigen, erzeugt Entwickler A (oder auch Entwickler B) einen Branch auf Basis des Master-Branchs, löst das Problem mit so vielen Commits wie erforderlich und mergt den Branch direkt in den Master zurück.

git checkout -b issue-#001 master
# Bug wird gefixt
git checkout master
git merge issue-#001
git push

Wie Release-Branches enthalten auch Maintenance-Branches wichtige Aktualisierungen, die auch im Develop-Branch enthalten sein müssen. Entwickler A muss also auch diesen Merge ausführen. Anschließend kann er den Branch gerne löschen:

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001

Fazit

Die bisher vorgestellten Workflows sollten einen guten Eindruck von den Potenzialen vermitteln, die lokale Repositories, das Push-Pull-Muster und das Branching- und Merging-Modell von Git bieten. Doch auch der Gitflow-Workflow ist lediglich ein Beispiel für einen effizienten Entwicklungsprozess mit Git und kein unveränderliches Reglement, das unbedingt strikt befolgt werden muss. Es ist kein Problem, einige Aspekte eines Workflows zu adaptieren und andere nicht zu berücksichtigen. Git passt sich Anforderungen und Arbeitsmethoden an.

Der kommende nächste Teil der Reihe bietet mit dem Forking-Workflow ein weiteres Beispiel.

Weiterführende Infos: Ihr Partner für Git und Stash

Kennen Sie Stash von Atlassian? Stash bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben.

Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Pertner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Stash. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.

Git und Stash in der Software-Entwicklung: Eine Einführung
Stash in der Praxis
Stash Enterprise: Git-Repository-Management in großen Unternehmen
So funktioniert die Lizenzierung von Atlassian-Produkten