GitFlow: Saubere Branch-Struktur für Teams

GitFlow ist ein Branch-Modell für Git, das Teams eine feste Struktur für die Entwicklung, Veröffentlichung und Wartung von Software vorgibt. Es wurde 2010 von Vincent Driessen vorgestellt und ist bis heute eines der bekanntesten Workflows. GitFlow unterscheidet dauerhafte Zweige (main, develop) und temporäre Zweige (Feature, Release, Hotfix) mit klaren Regeln, wann was wohin gemerged wird.

Die Zweige im Überblick

main        → immer produktionsreif, jeder Commit ist ein Release-Stand
develop     → Integrationszweig, alle Features sammeln sich hier
feature/*   → neue Funktionen, abgezweigt von develop
release/*   → Vorbereitung einer Veröffentlichung, abgezweigt von develop
hotfix/*    → dringende Fixes im Produktivbetrieb, abgezweigt von main
  • main: Der stabile Stand. Tags markieren Releases (z. B. v1.2.0). Hier wird nie direkt entwickelt.
  • develop: Der gemeinsame Arbeitsstand. Fertige Features werden hier zusammengeführt.
  • feature/<name>: Für jede neue Funktion ein eigener Zweig von develop — so bleibt main und develop jederzeit lauffähig. Nach dem Merge wird der Feature-Zweig gelöscht.
  • release/<version>: Kurz vor einem Release abgezweigt; hier werden nur noch Fehler behoben und die Version vorbereitet. Nach dem Merge in main und develop wird ein Tag gesetzt.
  • hotfix/<name>: Für dringende Produktionsfehler, abgezweigt von main — damit der Fix nicht von unfertigen Features in develop abhängt.

Typischer Ablauf

1. Feature-Zweig von develop abzweigen (feature/login)
2. Entwickeln + committen + Pull Request / Review
3. Merge nach develop
4. Wenn genug Features fertig: release/1.3.0 von develop abzweigen
5. Release-Tests und kleine Fixes im Release-Zweig
6. Merge nach main, Tag v1.3.0 setzen, Merge zurück nach develop
7. Produktionsfehler → hotfix/… von main → Merge nach main + develop

Vorteile

  • Klare Trennung: Entwickler wissen immer, welcher Zweig wofür da ist — gerade in größeren Teams wichtig.
  • Stabiler Produktivstand: main ist jederzeit veröffentlichbar; Releases entstehen kontrolliert über Release-Zweige.
  • Nachvollziehbarkeit: Die Historie zeigt genau, welche Features in welches Release eingegangen sind.
  • Parallelarbeit: Mehrere Features und Hotfixes laufen gleichzeitig, ohne sich zu stören — das unterstützt die CI/CD-Automatisierung mit Tests pro Zweig.

Wann besser nicht?

  • Für kleine Teams oder kontinuierliches Deployment ist GitFlow oft zu schwergewichtig. Einfachere Modelle (GitHub Flow: nur main + Feature-Zweige) sind dann schneller.
  • Wer mehrmals täglich releast, braucht keine Release-Zweige — da stört die Struktur eher.
  • GitFlow funktioniert am besten, wenn Releases geplant und versioniert werden (klassische Software-Versionen, nicht „immer live").

Praxis-Tipps

  • Merge-Konventionen im Team festlegen (Merge-Commit vs. Squash) und im Pipeline-Workflow dokumentieren.
  • Jeden Zweig automatisch testen lassen — die Pipeline fängt Fehler, bevor sie nach develop oder main kommen.
  • Regeln per Branch-Protection erzwingen: Kein direkter Push auf main/develop, nur Pull Requests.
  • Hotfixes sind der häufigste Fehlerpunkt — immer von main abzweigen und in beide Zweige mergen.

Verwandte Grundlagen: Git, CI/CD, Pipeline, Testing, Automatisierung, Monitoring, Snapshots.