232 lines
13 KiB
Markdown
232 lines
13 KiB
Markdown
---
|
||
title: Git-flow-Workflow | Atlassian Git Tutorial
|
||
source: https://www.atlassian.com/de/git/tutorials/comparing-workflows/gitflow-workflow
|
||
tags:
|
||
- IT/Development/Git
|
||
- IT/Tools/Gitflow
|
||
---
|
||
|
||
## [Git-flow-Workflow | Atlassian Git Tutorial](https://www.atlassian.com/de/git/tutorials/comparing-workflows/gitflow-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](https://www.atlassian.com/de/continuous-delivery/continuous-integration/trunk-based-development) Workflows getreten, die in der modernen kontinuierlichen Softwareentwicklung und im [DevOps](https://www.atlassian.com/de/devops/what-is-devops)-Bereich zum Einsatz kommen. Hinzu kommt, dass sich Gitflow nur schwierig in [CI/CD](https://www.atlassian.com/de/continuous-delivery)-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](http://nvie.com/posts/a-successful-git-branching-model/) veröffentlicht und bekannt gemacht. Gitflow verfügt im Gegensatz zur Trunk-basierten Entwicklung über mehr und langlebigere Branches sowie größere Commits. Unter diesem Modell erstellen Entwickler einen Feature-Branch und verzögern den Merge mit dem Haupt-Trunk-Branch, bis 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](https://www.atlassian.com/de/devops/what-is-devops/devops-best-practices) der [Continuous Delivery](https://www.atlassian.com/de/continuous-delivery). Dieser Workflow fügt keine neuen Konzepte oder Befehle hinzu, die über das für den [Feature-Branch-Workflow](https://www.atlassian.com/de/git/tutorials/comparing-workflows/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.
|
||
|
||
## 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](https://git-scm.com/download/win). 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](https://www.atlassian.com/de/git/tutorials/setting-up-a-repository/git-init)`. In deinem Repository ändert sich dabei nichts, außer dass jetzt Branches für dich erstellt werden können.
|
||
|
||
## Wie es funktioniert
|
||
|
||
|
||
|
||
### 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:
|
||
|
||
```shell
|
||
git branch develop
|
||
git push -u origin develop
|
||
```
|
||
|
||
Dieser 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:
|
||
|
||
```shell
|
||
$ 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
|
||
main
|
||
|
||
|
||
```
|
||
|
||
## Feature Branches
|
||
|
||
Jedes neue Feature sollte sich auf seinem eigenen Branch befinden, der zu Sicherungs-/Zusammenarbeitszwecken [zum zentralen Repository gepusht werden kann](https://www.atlassian.com/de/git/tutorials/syncing/git-push). 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](https://www.atlassian.com/de/git/tutorials/using-branches/git-merge). 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_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:
|
||
|
||
```shell
|
||
git checkout develop
|
||
git merge feature_branch
|
||
```
|
||
|
||
Mit der Git-flow-Erweiterung:
|
||
|
||
```shell
|
||
git flow feature finish feature_branch
|
||
```
|
||
|
||
## Release-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:
|
||
|
||
```shell
|
||
git checkout develop
|
||
git checkout -b release/0.1.0
|
||
```
|
||
|
||
Mit der Git-flow-Erweiterung:
|
||
|
||
```shell
|
||
$ 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:
|
||
|
||
```shell
|
||
git checkout main
|
||
git merge release/0.1.0
|
||
```
|
||
|
||
Mit der Git-flow-Erweiterung:
|
||
|
||
```shell
|
||
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:
|
||
|
||
```shell
|
||
git checkout main
|
||
git checkout -b hotfix_branch
|
||
```
|
||
|
||
Mit der Git-flow-Erweiterung:
|
||
|
||
```shell
|
||
$ 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.
|
||
|
||
```shell
|
||
git checkout main
|
||
git merge hotfix_branch
|
||
git checkout develop
|
||
git merge hotfix_branch
|
||
git branch -D hotfix_branch
|
||
```
|
||
|
||
```shell
|
||
$ 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 `main`-Branch eingerichtet.
|
||
|
||
```shell
|
||
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_branch
|
||
```
|
||
|
||
Zusätzlich zum `feature` Workflow und `release` Workflow sieht ein `hotfix`-Beispiel folgendermaßen aus:
|
||
|
||
```shell
|
||
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_branch
|
||
```
|
||
|
||
## Zusammenfassung
|
||
|
||
Wir haben hier den Git-flow-Workflow besprochen. Git-flow ist eine der vielen Varianten des [Git-Workflows](https://www.atlassian.com/de/git/tutorials/comparing-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.
|
||
- 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 `main`-Branch 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 `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](https://www.atlassian.com/de/git/tutorials/comparing-workflows/forking-workflow) oder sieh dir unseren [Workflow-Vergleich](https://www.atlassian.com/de/git/tutorials/comparing-workflows) an. |