Git Flow: Was es ist, Verzweigungsmodell und Einsatz in Projekten

Was ist Git Flow?

Git Flow ist ein Git-Verzweigungsmodell, das eine strenge Struktur von Branches und Merge-Regeln für die Verwaltung von Entwicklung, Releases und Korrekturen vorgibt. Vincent Driessen veröffentlichte den Artikel „A successful Git branching model“ im Januar 2010, und seitdem ist Git Flow zum De-facto-Standard in der Unternehmensentwicklung mit Java und .NET geworden. Die Hauptidee ist, den Code in fünf Branch-Typen mit unterschiedlichen Stabilitätsgraden zu unterteilen.

Laut Atlassian Git Tutorials, 2024 basiert Git Flow auf zwei permanenten Branches: Main (früher Master) und Develop. Alle anderen Branches sind temporär: Feature, Release, Hotfix. Jeder Branch-Typ hat einen klar definierten Lebenszyklus und Merge-Regeln. In der mobilen Entwicklung wird Git Flow in Projekten mit regelmäßigen Release-Zyklen (2–4 Wochen) und Unterstützung mehrerer Versionen eingesetzt.

Git Flow unterscheidet sich durch die Anforderung eines separaten Develop-Branches für die Integration von einfacheren Modellen (GitHub Flow). Dies fügt dem Merge-Prozess einen Schritt hinzu, bietet aber zusätzliche Isolierung unfertiger Features vom releasebereiten Code.

Vincent Driessen und die Geschichte von Git Flow

Im Jahr 2010 veröffentlichte Vincent Driessen den Post „A successful Git branching model“, der zu einem der meistzitierten in der Git-Geschichte wurde. Das Modell wurde für ein Projekt mit festen Releases und paralleler Versionsunterstützung entwickelt. Im Jahr 2020 erkannte Driessen an, dass Git Flow für moderne CI/CD-Praktiken veraltet ist, aber das Modell bleibt für Projekte mit langen Release-Zyklen und der Notwendigkeit der Unterstützung älterer Versionen relevant.

# Git Flow initialisieren
git flow init

# Feature-Branch erstellen
git flow feature start "add-auth"

# Feature-Branch abschließen (in Develop mergen)
git flow feature finish "add-auth"

# Release erstellen
git flow release start "1.2.0"
git flow release finish "1.2.0"

Main-Branch: Release-Code und Tagging

Main (früher Master) ist der Hauptbranch, der nur Release-Code enthält, der für die Bereitstellung bereit ist. Jeder Commit in Main sollte einer bestimmten Produktversion entsprechen, die im semantischen Versionierungsformat getaggt ist, z. B. v1.0.0, v1.1.0. In Main wird keine direkte Entwicklung durchgeführt — Änderungen gelangen nur über Release- oder Hotfix-Branches hierher.

Laut semver.org, 2024 verwenden Tags in Main das MAJOR.MINOR.PATCH-Format. MAJOR wird für inkompatible API-Änderungen erhöht, MINOR für das Hinzufügen von Funktionalität mit Abwärtskompatibilität, PATCH für Fehlerbehebungen. In Git Flow erstellt jeder fertiggestellte Release automatisch einen Commit in Main mit einem Versionstag.

Der Main-Branch ist der einzige, der in der Produktion bereitgestellt wird. Für mobile Projekte bedeutet dies, dass ein Push zu Main die App Bundle- oder IPA-Build-Pipeline und die Veröffentlichung im Google Play / App Store auslöst. In den CI/CD-Einstellungen von GitLab ist Main vor Force-Push und Löschung geschützt.

Semantische Versionierung und Tags

Jeder Commit in Main wird von einem Tag im SemVer-Format begleitet: vMAJOR.MINOR.PATCH. MAJOR — für inkompatible API-Änderungen, MINOR — für neue Funktionen mit Abwärtskompatibilität, PATCH — für Fehlerbehebungen. Beispiel: v2.1.0 bedeutet das zweite Major-Release mit neuen Funktionen und ohne Fehlerbehebungen. In Git Flow werden Tags automatisch beim Abschließen eines Releases oder Hotfixes über den Befehl git flow release finish erstellt.

Develop-Branch: Integrationslinie der Entwicklung

Develop ist der zweite permanente Branch in Git Flow, der für die Integration aller abgeschlossenen Features konzipiert ist. Entwickler mergen Feature-Branches in Develop, nachdem sie Code-Review und CI/CD-Prüfungen bestanden haben. Develop enthält die neueste stabile Version des Codes, einschließlich aller implementierten Features des aktuellen Sprints.

Laut DataSift Git Flow Guide, 2024 kann Develop aufgrund laufender Integrationen vorübergehend instabil sein. Um Probleme zu vermeiden, praktizieren Teams kontinuierliche Integration (CI): Jedes Feature muss vor dem Merge in Develop eine vollständige Testsuite bestehen. Wenn CI fehlschlägt, korrigiert der Entwickler den Code vor dem nächsten Merge. Develop ist immer mit der aktuellen Version von Main verbunden: Sofort nach einem Release wird Develop durch einen Merge mit Main synchronisiert.

Feature-Branches: Entwicklung neuer Funktionalität

Feature-Branches sind temporäre Branches für die Entwicklung einzelner Features, Fehlerbehebungen oder Experimente. Jeder Feature-Branch wird von Develop erstellt und nach Fertigstellung zurück in Develop gemergt. Der Name des Feature-Branches enthält normalerweise die Aufgabenummer oder eine kurze Beschreibung: feature/APP-123-add-oauth, feature/redesign-profile. In Git Flow können Feature-Branches unbegrenzt existieren.

Laut Pro Git Book, 2024 sind Feature-Branches eine isolierte Entwicklungsumgebung: Änderungen in einem Branch wirken sich bis zum Merge nicht auf andere aus. In mobilen Projekten werden Feature-Branches durch Rebase oder Merge mit Develop synchronisiert, um große Konflikte beim Abschluss zu vermeiden. Es wird empfohlen, den Feature-Branch vor der Erstellung eines MR auf Develop zu rebasen.

# Manuelle Feature-Branch-Erstellung (ohne git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# MR in GitLab über CLI erstellen
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release-Branches: Vorbereitung eines Releases

Release-Branches sind temporäre Branches, die von Develop erstellt werden, um ein Release vorzubereiten. Wenn Develop genügend Features für eine neue Version enthält, erstellt das Team einen Release/X.Y.Z-Branch (z. B. release/2.1.0). In diesem Branch werden nur letzte Änderungen vorgenommen: Versionserhöhung, Aktualisierung der Lokalisierung, letzte Tests, kritische Fehlerbehebungen.

Laut Atlassian Git Tutorials, 2024 löst der Release-Branch ein zentrales Problem: die Isolierung letzter Änderungen von der parallelen Entwicklung. Während das Release vorbereitet wird, werden weiterhin neue Features für das nächste Release in Develop gemergt. Nach Abschluss wird der Release-Branch in Main (mit Tag) und in Develop (zur Synchronisierung der Versionserhöhung) gemergt.

Hotfix-Branches: Dringende Korrekturen in der Produktion

Hotfix-Branches sind temporäre Branches für die dringende Behebung kritischer Fehler in der Produktion. Der einzige Branch-Typ in Git Flow, der von Main und nicht von Develop erstellt wird. Namensformat: hotfix/X.Y.Z+1 (z. B. hotfix/2.1.1). Nach Abschluss wird der Hotfix-Branch gleichzeitig in Main (als neuer Patch-Release) und in Develop (damit die Korrektur in zukünftigen Releases nicht verloren geht) gemergt.

Laut DataSift Git Flow Guide, 2024 sollten Hotfix-Branches so kurz wie möglich sein — nur die Korrektur und der Test. Ein Hotfix sollte keine neuen Funktionen oder Refactoring enthalten. In der mobilen Entwicklung werden Hotfixes für kritische Abstürze (Absturzrate > 0,1 %), Sicherheitslücken oder blockierende Fehler im App Store verwendet.

Vor- und Nachteile von Git Flow für die mobile Entwicklung

Git Flow bietet eine klare Struktur, die besonders für große Teams und Projekte mit regelmäßigen Releases nützlich ist. Vorteile: Isolierung unfertiger Features in Feature-Branches, Möglichkeit, ein Release vorzubereiten ohne die Entwicklung zu blockieren, Unterstützung mehrerer Versionen durch Hotfixes. Nachteile: Komplexität für Anfänger, Notwendigkeit regelmäßiger Rebase von Feature-Branches, Konflikte bei langlebigen Branches.

Laut Martin Fowler, 2024 ist der Hauptnachteil von Git Flow die langlebigen Feature-Branches. Wenn ein Feature 2+ Wochen ohne Synchronisation mit Develop entwickelt wird, wird der Merge-Konflikt erheblich. Für mobile Projekte wird empfohlen, den Feature-Branch täglich durch Rebase auf Develop zu synchronisieren.

Git Flow wird nicht für Projekte mit Continuous Deployment (jeder Commit in Main → Produktion) empfohlen. Für solche Projekte bieten GitHub Flow oder Trunk-Based Development ein einfacheres und schnelleres Modell. Aber für Projekte mit Release-Zyklen und Unterstützung älterer Versionen bleibt Git Flow die optimale Wahl.

Wann Git Flow für das Team schädlich ist

Git Flow wird in drei Fällen zum Problem: Teams mit weniger als 5 Personen (unnötige Komplexität), Continuous Deployment (Verzögerung der Auslieferung), fehlende Rebase-Disziplin (langlebige Feature-Branches erzeugen Merge-Konflikte). Wenn ein Team mehr als 20 % seiner Zeit mit dem Mergen von Branches und der Konfliktlösung verbringt — dann ist Git Flow für dieses Team nicht geeignet, selbst wenn es groß ist.

Alternativen zu Git Flow: GitHub Flow und Trunk-Based Development

Alternativen zu Git Flow bieten einen einfacheren Prozess für Teams, die CI/CD praktizieren. GitHub Flow verwendet nur einen permanenten Branch (Main) und Feature-Branches. Jedes Feature wird von Main erstellt, nach Review und CI zurück in Main gemergt und sofort bereitgestellt. GitHub Flow ist einfacher, unterstützt aber keine Isolierung unfertiger Features oder parallele Release-Vorbereitung.

Laut GitHub Docs, 2024 geht Trunk-Based Development (TBD) noch weiter: Alle Entwickler arbeiten in einem einzigen Branch (Trunk) und verwenden kurzlebige Feature-Branches von 1–2 Tagen. Feature Toggles steuern die Sichtbarkeit unfertigen Codes. TBD erfordert hohe CI/CD-Disziplin und Testautomatisierung.

• GitHub Flow — ein Main + Feature-Branches, ideal für CI/CD und kleine Teams
• GitLab Flow — erweitert Git Flow mit Umgebungs-Branches (Staging, Production)
• Trunk-Based Development — ein Branch + Feature Toggles, maximales CI/CD, minimale Merges
• One Flow — vereinfachter Git Flow ohne Develop-Branch, nur Main + Feature + Release