Git-Workflows: Der Gitflow-Workflow (Teil 1)

Diese Reihe von Artikeln beschäftigt sich mit Workflows für Entwicklungsteams, die Git als verteiltes Versionskontrollsystem adaptieren. Nach dem zentralisierten und dem Feature-Branch-Workflow geht es nun um den Gitflow-Workflow, der sich weitere Vorteile von Git zunutze macht und einen belastbaren Rahmen für große Software-Projekte bietet.

Der Gitflow-Workflow

Dieser Workflow definiert ein striktes Branching-Modell, das auf die nahtlose Auslieferung von Releases abzielt. Er ist sicherlich komplexer als der Feature-Branch-Workflow, bietet aber einen robusten Rahmen für das Management großer Projekte. Der Workflow sieht keine neuen Konzepte oder Befehle vor, weist verschiedenen Branches jedoch strikte Rollen zu, die festlegen, wie und wann sie interagieren sollten. Natürlich bietet auch der Gitflow-Workflow alle Vorteile des Feature-Branch-Modells: Pull-Requests, isolierte Experimente und eine effizientere Zusammenarbeit.

Der Gitflow-Workflow nutzt ebenfalls ein zentrales Repository als Kommunikations-Drehkreuz für alle Entwickler. Und wie bei den anderen Workflows arbeiten die Entwickler lokal und pushen Branches in das zentrale Repository. Der Unterschied liegt in der Branch-Struktur des Projekts.

Statt eines einzelnen Master-Branchs sieht dieser Workflow zwei Branches vor, die die History des Projekts abbilden. Der Master-Branch enthält die offizielle Release-Historie, der Develop-Branch dient als Integrations-Branch für Features. Es ist zudem üblich, alle Commits in den Master-Branch mit Versionsnummern zu taggen.

Gitflow-Workflow 1

Der Rest des Workflows dreht sich um die Unterschiede zwischen diesen beiden Branches.

Feature-Branches

Jedes neue Feature sollte in seinem eigenen Branch entwicklt werden, der für Backups und aus Gründen der Zusammenarbeit in das zentrale Repository gepusht werden kann. Doch statt Branches auf Basis des Master-Branchs zu erzeugen, wird der Develop-Branch als Quelle genutzt. Wenn ein Feature fertig ist, wird es zurück in diesen Develop-Branch gemergt. Dieser Workflow sieht vor, dass Features niemals direkt mit dem Master-Branch interagieren.

Gitflow-Workflow 2

Die Kombination von Feature-Branches und dem Develop-Branch entspricht soweit dem Feature-Branch-Workflow. Doch der Gitflow-Prozess geht darüber hinaus.

Release-Branches

Gitflow-Workflow 3

Wenn der Develop-Branch genügend Features für ein Release enthält (oder sich ein vordefinierter Release-Termin nähert), wird vom Develop-Branch ein Release-Branch geforkt. Damit beginnt der nächste Release-Zyklus; neue Features sollten ab diesem Punkt nicht mehr hinzugefügt werden, sondern nur Bugfixes und ähnliche Release-orientierte Änderungen. Ist es zur Auslieferung bereit, wird das Release in den Master-Branch gemergt und mit einer Versionsnummer getaggt. Zusätzlich sollte es zurück in den Develop-Branch gemergt werden, der sich weiterentwickelt haben könnte, seitdem das Release initiiert wurde.

Die Nutzung eines dedizierten Branches zur Vorbereitung von Releases ermöglicht es, dass ein Team das aktuelle Release feinschleift, während das andere Team weiter an Features für das nächste Release arbeitet. Auf diese Weise lassen sich auch bestimmte Entwicklungsphasen sehr gut definieren. (Beispielsweise kann man problemlos sagen "Diese Woche bereiten wie Version 4.0 vor" und sieht dies auch tatsächlich in der Struktur der Repository.)

Konventionen:
Branchen von: develop
Mergen in: master
Naming-Konvention: release-* oder release/*

Maintenance-Branches

Gitflow-Workflow 4

Maintenance- oder Hotfix-Branches eignen sich für das Patchen von Produktiv-Releases. Ein solcher Branch ist der einzige, der direkt vom Master geforkt wird. Sobald die Probleme gefixt sind, wird er sowohl in den Master- als auch in den Develop-Branch (oder den aktuellen Release-Branch) gemergt; der Master wird mit einer aktualisierten Versionsnummer getaggt.

Durch eine solche dedizierte Entwicklungslinie für Bugfixes kann ein Team Probleme des Produktiv-Releases 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.

Wie ein Team konkret nach dem Gitflow-Workflow arbeiten kann, verdeutlicht das Beispiel im Folgeartikel.

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 Partner 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

Kennen Sie schon Linch & Pin?

Linch&Pin_Banner_gross_Schatten_lang