Git-flow-Workflow
Gitflow ist ein veralteter Git-Workflow der einst eine disruptive und neuartige Strategie für die Verwaltung von Git-Branches darstellte. An die Stelle von Gitflow sind mittlerweile Trunk-basierte Workflows getreten, die in der modernen kontinuierlichen Softwareentwicklung und im DevOps-Bereich zum Einsatz kommen. Hinzu kommt, dass sich Gitflow nur schwierig in CI/CD-Prozesse integrieren lässt. Dieser Artikel zu Gitflow dient lediglich der historischen Einordnung.
Was ist Gitflow?
Gitflow ist ein alternatives Git-Branching-Modell, das Feature-Branches und mehrere primäre Branches verwendet. Er wurde erstmals von Vincent Driessen auf nvie veröffentlicht und bekannt gemacht. Gitflow verfügt im Gegensatz zur Trunk-basierten Entwicklung über mehr und langlebigere Branches sowie größere Commits. Bei diesem Modell erstellen Entwickler einen Feature-Branch und führen den Merge mit dem Haupt-Trunk-Branch erst durch, wenn das Feature vollständig ist. Diese langlebigen Feature-Branches erfordern mehr Zusammenarbeit bei Merges und haben ein höheres Risiko, vom Trunk-Branch abzuweichen. Außerdem können sie womöglich konfliktbehaftete Updates einführen.
Gitflow kann für Projekte genutzt werden, die einen geplanten Release-Zyklus haben, sowie für die DevOps-Best-Practices der Continuous Delivery. Dieser Workflow fügt keine neuen Konzepte oder Befehle hinzu, die über das für den Feature-Branch-Workflow Erforderliche hinausgehen. Stattdessen weist er verschiedenen Branches äußerst spezifische Rollen zu und definiert, wie und wann diese interagieren sollen. Zusätzlich zu Feature-Branches verwendet er einzelne Branches zum Vorbereiten, Verwalten und Aufzeichnen von Releases. Natürlich kannst du auch alle Vorteile des Feature-Branch-Workflows nutzen: Pull-Anfragen, isolierte Experimente und eine effizientere Zusammenarbeit.
Zugehöriges Material
Git-Protokoll für Fortgeschrittene
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
Wie funktioniert "git revert"?
Develop- und Haupt-Branches
Statt eines einzelnen main-Branch sieht dieser Workflow zwei Branches vor, um den Verlauf des Projekts aufzuzeichnen. Der main-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 main-Branch mit einer Versionsnummer zu taggen.
Der erste Schritt ist, den obligatorischen main- 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 developDieser Branch wird den kompletten Versionsverlauf des Projekts enthalten, während der main-Branch 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 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: [main]
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
mainFeature Branches
Schritt 1: Erstelle das Repository.
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 main-Branch 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 main-Branch interagieren.
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 Git-flow-Erweiterungen:
git checkout develop
git checkout -b feature_branchMit der Git-flow-Erweiterung:
git flow feature start feature_branchSetze 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_branchMit der Git-flow-Erweiterung:
git flow feature finish feature_branchRelease-Branches
Wenn der develop-Branch genügend Features für ein Release enthält (oder ein festgelegter 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 main-Branch 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 folgenden Methoden erstellt werden.
Ohne die Git-flow-Erweiterungen:
git checkout develop
git checkout -b release/0.1.0Mit der Git-flow-Erweiterung:
$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'Ist der Release bereit zur Auslieferung, wird er in den main-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 Git-flow-Erweiterungen:
git checkout main
git merge release/0.1.0Mit der Git-flow-Erweiterung:
git flow release finish '0.1.0'Hotfix Branches
Maintenance- 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 main- statt auf dem develop-Branch. Dies ist der einzige Branch, der direkt vom main-Branch geforkt werden sollte. Sobald der Fix abgeschlossen wurde, sollte er sowohl in den main- als auch in den develop-Branch (oder den aktuellen release-Branch) gemergt werden; der main-Branch 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 main-Branch interagieren. Einen hotfix-Branch kannst du mithilfe folgender Methoden erstellen:
Ohne die Git-flow-Erweiterungen:
git checkout main
git checkout -b hotfix_branchMit der Git-flow-Erweiterung:
$ git flow hotfix start hotfix_branchÄhnlich wie beim Abschluss eines release-Branch wird ein hotfix-Branch sowohl in den main- als auch in den develop-Branch gemergt.
git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch$ git flow hotfix finish hotfix_branchBeispiel
Im Folgenden siehst du ein vollständiges Beispiel für einen Feature-Branch-Workflow. Nehmen wir an, wir haben ein Repository mit einem main-Branch eingerichtet.
git checkout main
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout main
git merge develop
git branch -d feature_branchZusätzlich zum feature Workflow und release Workflow sieht ein hotfix-Beispiel folgendermaßen aus:
git checkout main
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout main
git merge hotfix_branchZusammenfassung
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 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:
1. Ein develop-Branch wird auf Basis des main-Branch erstellt.
2. Ein release-Branch wird vom develop-Branch erstellt.
3. Ein feature-Branch wird 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 main-Branch gemergt.
6. Taucht ein Problem im main-Branch auf, wird ein hotfix-Branch auf Basis des main-Branch erstellt.
7. Sobald der hotfix abgeschlossen ist, wird er in den develop-Branch und den main-Branch gemergt.
Fahre nun fort mit dem Forking-Workflow oder sieh dir unseren Workflow-Vergleich an.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
Bitbucket-Blog
DevOps-Lernpfad
