GitFlow-Tutorial: Branching für Features, Releases und Hotfixes

GitFlow einrichten

Bevor du von GitFlows strukturiertem Branching profitierst, musst du es auf deinem Rechner installieren und im Repository initialisieren. Zum Glück sind beide Schritte unkompliziert.

Um GitFlow zu nutzen, sollte Git bereits auf deinem Rechner installiert sein. Mehr zur Installation erfährst du im Git Install Tutorial.

GitFlow installieren

GitFlow ist eine Erweiterung für Git und wird separat installiert. Standardmäßig ist es nicht in Git enthalten. Der Installationsprozess hängt von deinem Betriebssystem ab.

Ausführlichere Anweisungen zur Installation von GitFlow findest du in der offiziellen Dokumentation.

Hinweis: Die oben genannte GitFlow-Erweiterung macht das Verwalten von Feature-Branches, Releases und Hotfixes mit einfachen Befehlen leichter, ist aber nicht zwingend erforderlich. Du kannst dem GitFlow-Workflow auch mit standardmäßigen Git-Befehlen folgen — solange du bei Namenskonventionen und Merge-Praktiken konsequent bleibst. Das Tool automatisiert und erzwingt den Prozess lediglich, was besonders für Teams oder größere Projekte hilfreich ist.

macOS

Wenn du Homebrew nutzt, den beliebtesten Paketmanager für macOS, führe aus:

brew install git-flow-avh

Linux (Debian/Ubuntu-basiert)

Wenn du ein Debian-basiertes System wie Ubuntu nutzt, verwende:

sudo apt-get install git-flow

Windows

Unter Windows kannst du GitFlow über Git for Windows installieren und Git Bash zu deinem Terminal hinzufügen.

Ob GitFlow installiert ist, prüfst du mit:

git flow version

GitFlow in einem Repository initialisieren

Als ersten Schritt brauchst du ein initialisiertes Git-Repository, bevor du GitFlow verwenden kannst. Mehr dazu in How to Initialize and Set Up a Git Repository.

Sobald GitFlow installiert ist, kannst du es in jedem bestehenden Repository initialisieren mit:

git flow init

GitFlow fordert dich auf, einige Einstellungen zu konfigurieren. Hier ist die Bedeutung und wie du passende Werte auswählst:

1. Branch-Namen: Du wirst nach den Standard-Branch-Namen gefragt.
1. Produktions-Branch (Standard: master)
2. Entwicklungs-Branch (Standard: develop)
2. Präfixe für Unterstützungs-Branches: GitFlow nutzt Namenskonventionen für die verschiedenen Branch-Typen.
1. Feature-Branches: feature/
2. Bugfix-Branches: bugfix/
3. Release-Branches: release/
4. Hotfix-Branches: hotfix/
5. Support-Branches: support/ (in der Praxis selten)
6. Version-Tag-Präfix: v (z. B. v.1.2.0)

Die Standardwerte funktionieren für die meisten Teams gut, lassen sich aber an die Namensstandards deiner Organisation anpassen.

Beispielausgabe der Initialisierung:

git flow init

Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? [] v

Nach der Initialisierung kannst du den develop-Branch in dein Remote-Repository pushen. Mehr zum Pushen und Pullen von Branches findest du im Git Push and Pull Tutorial.

GitFlow in der Entwicklung einsetzen

Sobald GitFlow in deinem Repository eingerichtet ist, kannst du das Branching-Modell nutzen, um deinen Entwicklungs-Workflow zu steuern. GitFlow stellt High-Level-Befehle für Features, Releases und Hotfixes bereit, die Struktur sichern und Git-Chaos vermeiden.

In den nächsten Unterkapiteln schauen wir uns GitFlow in der Praxis an.

Feature-Branches erstellen

Feature-Branches dienen dazu, neue Funktionen zu entwickeln, ohne die Haupt-Codebasis zu beeinflussen.

Einen Feature-Branch erstellst du mit:

git flow feature start <feature-name>

Dieser Befehl erstellt einen neuen Branch von develop namens feature/<feature-name>. Du kannst nun dein Feature entwickeln und wie gewohnt committen.

Feature-Branches abschließen

Wenn dein Feature fertig und getestet ist, schließt du es mit: 

git flow feature finish <feature-name>

Das bewirkt Folgendes:

• Mergt deinen Feature-Branch in develop.
• Löscht den lokalen Branch feature/<feature-name>.

Bei Merge-Konflikten löse sie manuell und schließe den Merge über den üblichen Git-Konfliktlösungsprozess ab.

Wenn du in größeren Teams arbeitest, in denen zunächst Pull Requests erstellt und reviewed werden müssen, kannst du den GitFlow-Finish-Befehl nicht direkt nutzen. Stattdessen kannst du so vorgehen:

1. Commite deine Arbeit und pushe den Branch:

git push origin feature/<feature-name>

2. Erstelle einen Pull Request von feature/<feature-name> nach develop auf GitHub, GitLab etc.
3. Fordere Reviews an, führe Tests aus und hole Freigaben ein.
4. Nach Freigabe per UI der Plattform mergen und den Branch löschen.

Wenn du mehr über GitHub und die Nutzung lernen willst, empfehle ich die Kurse GitHub Foundations und GitHub Concepts. In anderen Teams kannst du dem Standardflow git flow feature finish folgen, solltest aber vor dem Merge nach develop ein Review einholen und Tests für deine Änderungen ausführen.

Release-Branches erstellen

Release-Branches werden erstellt, um eine neue Produktionsversion vorzubereiten, ohne die laufende Entwicklung auf develop zu blockieren.

Ein Release startest du so:

git flow release start <version-number>

Dadurch entsteht ein Branch release/<version-number>, der von develop abzweigt.

In diesem Branch finalisierst du in der Regel Versionsnummern, behebst kleinere Bugs und aktualisierst Doku und Changelogs.

Release-Branches abschließen

Sobald dein Release produktionsreif ist, schließt du es mit:

git flow release finish <version-number>

Dieser Befehl:

• Merget den Release-Branch in master und develop.
• Taggt das Release in master (z. B. v1.0.0).
• Löscht den lokalen Branch release/<release-number>.

Vergiss nicht, Änderungen und Tags zu pushen:

git push origin master
git push origin develop
git push --tags

# oder kurz
git push origin master develop --tags

Hotfix-Branches erstellen

Hotfixes nutzt du für dringende Produktionsfixes, wenn ein Bug im master-Branch entdeckt wird.

Einen Hotfix startest du so:

git flow hotfix start <version-number>

Dadurch entsteht ein Branch hotfix/<version-number> von master. Jetzt kannst du Änderungen anwenden und den Fix committen.

Abschließen kannst du ihn mit:

git flow hotfix finish <version-number>

Das bewirkt:

• Der Hotfix wird in master und develop gemerged.
• Der Fix wird auf master getaggt.
• Der lokale Branch `hotfix/<version-number> wird gelöscht.

Pushe deine lokalen Änderungen und Tags wie gewohnt:

git push origin master develop --tags

Hotfixes sind besonders stark, weil du Produktionsprobleme schnell beheben kannst, ohne die laufende Entwicklung auf develop zu beeinträchtigen.

Stell dir vor, auf develop sind bereits neue Features gemerged, die du noch nicht releasen willst, aber in der produktiven Anwendung muss ein kritischer Bug sofort gefixt werden. 

Genau hier helfen Hotfixes, da sie von master abzweigen und anschließend nur in develop zurückgemerged werden.

Beispiel: GitFlow-Branching

Lass uns zwei typische Workflows durchspielen — einen Feature-Zyklus und ein Release mit Hotfix —, um GitFlow in Aktion zu sehen und mit den klassischen Git-Befehlen zu vergleichen.

Im direkten Vergleich verstehst du besser, wie die GitFlow-Erweiterung mehrere Git-Schritte in einfache, standardisierte Befehle kapselt.

Für einen schnellen Überblick über klassische Git-Befehle empfehle ich das Complete Git Cheat Sheet. Für einen kompakten Einstieg in Git lies das GitHub and Git Tutorial for Beginners.

Feature-Entwicklungsworkflow

Angenommen, du implementierst ein neues Feature, mit dem sich Nutzer in deiner Anwendung authentifizieren können. Du nennst das Feature user-authentication.

Mit GitFlow:

git flow feature start user-authentication

# Am Feature arbeiten
git add .
git commit -m "feat: Implement basic user authentication"

# Wenn fertig:
git flow feature finish user-authentication

git push origin develop

Und mit regulärem Git:

# Manuell einen neuen Branch erstellen und wechseln
git checkout -b feature/user-authentication develop

# Am Feature arbeiten
git add .
git commit -m "Implement basic user authentication"

# Wenn fertig
git checkout develop
git merge feature/user-authentication
git branch -d feature/user-authentication
git push origin develop

Wie du siehst, reduziert GitFlow die Anzahl der Befehle und damit die Komplexität. Es ist auch weniger fehleranfällig, z. B. versehentlich in den falschen Branch zu mergen.

Wenn du mehr darüber lernen möchtest, wie Merges in Git funktionieren, lies Git Merge Tutorial: A Comprehensive Guide with Examples.

Nehmen wir nun an, du bereitest das Release 1.0.0 vor. Kurz nach dem Release wird ein kritischer Bug entdeckt, der per Hotfix behoben werden muss. 

Mit GitFlow:

# Ein Release starten
git flow release start 1.0.0

# Letzte Anpassungen, Versionsnummern aktualisieren
git commit -am "Prepare release v1.0.0"

# Release abschließen
git flow release finish 1.0.0
git push origin master develop --tags

Nun hast du den Bug gefunden und musst einen Hotfix erstellen:

# Hotfix starten
git flow hotfix start 1.0.1

# Fix anwenden
git commit -am "Fix login issue in production"

# Hotfix abschließen
git flow hotfix finish 1.0.1
git push origin master develop --tags

Und das Ganze noch einmal mit regulären Git-Befehlen:

# Release manuell
git checkout -b release/1.0.0 develop

# Änderungen vornehmen
git commit -am "Prepare release v1.0.0"

# Manuell mergen
git checkout master
git merge release/1.0.0
git tag -a v1.0.0 -m "Release v1.0.0"
git checkout develop
git merge release/1.0.0

# Release-Branch löschen
git branch -d release/1.0.0
git push origin master develop --tags

# Hotfix manuell
git checkout -b hotfix/1.0.1 master

# Fix anwenden
git commit -am "Fix login issue in production"
git checkout master
git merge hotfix/1.0.1
git tag -a v1.0.1 -m "Hotfix v1.0.1"
git checkout develop
git merge hotfix/1.0.1

# Hotfix-Branch löschen
git branch -d hotfix/1.0.1
git push origin master develop --tags

Best Practices für GitFlow

GitFlow ist mächtig und hilft dir, den Code deines Teams zu steuern. Damit du das Maximum aus der Struktur herausholst, solltest du ein paar Best Practices befolgen.

Diese Empfehlungen halten Branches sauber, reduzieren Merge-Konflikte und steigern die Teamproduktivität — besonders in der Zusammenarbeit.

Konsistente Branch-Namen

Konsistenz ist Schlüssel in der Zusammenarbeit. Halte dich an die Standard-Namenskonventionen von GitFlow, außer dein Team hat gute Gründe für Anpassungen.

Empfohlene Muster:

• Feature-Branches: feature/<feature-name>
• Release-Branches: release/<version-number>
• Hotfix-Branches: hotfix/<version-number>

Für mehrteilige Namen solltest du Kebab-Case verwenden (z. B. feature/user-authentication).

Kleine, häufige Änderungen

Langlebige Branches führen oft zu schmerzhaften Merges und riesigen Pull Requests, die schwer zu reviewen sind. 

Ich spreche aus Erfahrung — ich war schon öfter in der Merge-Konflikt-Hölle, und das willst du möglichst vermeiden!

Halte Feature-Branches daher kurzlebig und fokussiere dich auf eine Aufgabe. Commite und pushe regelmäßig, um Arbeit nicht zu verlieren oder zu weit von develop abzuweichen.

Kleine, inkrementelle Änderungen sind leichter zu testen, zu reviewen und zu integrieren.

Regelmäßig mit develop synchronisieren

Wenn du an einem Feature-Branch arbeitest, solltest du nicht hinterherhinken. Ziehe regelmäßig die neuesten Änderungen aus develop, um spätere Merge-Konflikte zu minimieren:

git checkout feature/<your-feature>
git fetch origin
git rebase origin/develop

Up-to-date zu bleiben macht die Integration reibungsloser und hält deine Änderungen kompatibel mit parallelen Arbeiten.

Vor dem Mergen reviewen und testen

Auch wenn GitFlow direktes Mergen mit Befehlen wie git flow feature finish unterstützt, solltest du für alle Merges in develop und master Pull Requests (PRs) bzw. Merge Requests (MRs) nutzen.

Vorteile:

• Ermöglicht Code-Reviews und Freigabe-Workflows
• Löst automatisierte CI/CD-Prüfungen aus
• Sorgt für eine nachvollziehbare Änderungshistorie

Das ist besonders in produktionsnahen Umgebungen wichtig, in denen Qualitätssicherung zählt.

GitFlow-Probleme beheben

Auch mit einem strukturierten Workflow wie GitFlow können Probleme auftreten, vor allem im Team oder bei lang laufenden Branches. 

Hier findest du die häufigsten Herausforderungen und wie du sie effektiv löst.

Merge-Konflikte

Merge-Konflikte sind in größeren Teams, die an einer Codebasis arbeiten, häufig und nervig.Sie entstehen typischerweise, wenn zwei Branches dieselben Codezeilen geändert haben.

So löst du Merge-Konflikte:

1. Stoppe den git flow finish-Prozess.
2. Merge den Branch manuell in sein Ziel:

git checkout develop
git merge feature/<your-feature>

3. Git fordert dich auf, Konflikte zu lösen. Öffne die betroffenen Dateien und suche nach Konfliktmarkierungen wie:

<<<<<<< HEAD
Code from develop
=======
Code from feature branch
>>>>>>> feature/my-feature

4. Bearbeite und bereinige den Code manuell.
5. Markiere die Dateien nach der Lösung als behoben:

git add <resolved-file>

6. Schließe den Merge mit:

git commit -m “resolve merge conflict …”

Veraltete Branches aufräumen

Manchmal enthält dein Repository überholte feature-, release- oder hotfix-Branches. Um Verwirrung zu vermeiden, halte dein Repo so schlank wie möglich.

So gehst du vor:

1. Alle lokalen Branches auflisten:

git branch

2. Einen lokalen Branch löschen:

git branch -d <branch-name>

3. Wenn der Branch noch nicht gemerged wurde und du sicher bist, dass er weg kann:

git branch -D <branch-name>

4. Einen Remote-Branch löschen:

git push origin --delete <branch-name>

Es ist wichtig, regelmäßig deine Branches zu prüfen und veraltete zu entfernen, um das Repository sauber zu halten.

Fazit

GitFlow ist ein robustes Gerüst für Zusammenarbeit, Klarheit und Kontrolle in deinem Entwicklungsworkflow. Ob Solo-Projekt mit mehreren Beteiligten oder Arbeit im großen Team — GitFlow hilft dir, den Überblick zu behalten, indem es Feature-Entwicklung, Releases und Hotfixes sauber trennt.

Als ich GitFlow das erste Mal nutzte, war es ein echter Wendepunkt. Kein Merge-Chaos mehr. Kein Rätselraten, welcher Branch wofür da ist. Jede Aufgabe hatte ihren Platz, jedes Release folgte einem wiederholbaren, verlässlichen Prozess. Seitdem habe ich GitFlow in jedem Team eingeführt, mit dem ich gearbeitet habe. Jedes Mal brachte es mehr Struktur, reibungslosere Zusammenarbeit und weniger Fehler.

In diesem Tutorial hast du gelernt:

• Was GitFlow ist und warum es hilft
• Wie man GitFlow installiert und initialisiert
• Wie man mit Features, Releases und Hotfixes arbeitet
• Best Practices, um typische Probleme zu vermeiden
• Wie du GitFlow mit modernen Workflows über Pull Requests kombinierst

Wenn du deinen Git-Workflow aufs nächste Level bringen willst, setze GitFlow in deinem nächsten Projekt ein. Und wenn dir die Grundlagen schon vertraut sind, denk darüber nach, es mit der CI/CD-Pipeline deines Teams, eurem Review-Prozess oder GitHub Actions zu verzahnen.