Git Flow vs. GitHub Flow: Welche Branching-Strategie passt

1. Warum die Branching-Strategie über mehr als nur Ordnung entscheidet

Eine Branching-Strategie ist kein Selbstzweck, sondern die Antwort auf eine sehr konkrete Frage: Wie arbeiten mehrere Entwickler gleichzeitig an einem Projekt, ohne sich gegenseitig zu blockieren, und wie gelangt Code kontrolliert von der lokalen Entwicklung bis ins Live-System? Ohne festgelegtes Modell entsteht fast immer derselbe Zustand: Branches mit kryptischen Namen, Merge-Konflikte kurz vor dem Release und ein main-Branch, dessen Zustand niemand mehr zuverlässig einschätzen kann. Das kostet Zeit in genau den Momenten, in denen Zeit am knappsten ist, kurz vor einem Kunden-Release.

Die beiden dominierenden Modelle, Git Flow und GitHub Flow, lösen dieses Problem mit fundamental unterschiedlichen Philosophien. Git Flow setzt auf klar getrennte Branch-Typen mit definierten Übergängen, GitHub Flow auf Einfachheit und einen einzigen releasefähigen Branch. Für PHP- und Magento-Teams, die zwischen Staging-, Test- und Produktivsystemen jonglieren, ist die Wahl der richtigen Strategie kein akademisches Detail, sondern hat direkten Einfluss auf Deployment-Häufigkeit, Hotfix-Geschwindigkeit und die Frage, wie viele Umgebungen synchron gehalten werden müssen.

2. Git Flow erklärt: develop, feature, release und hotfix Branches

Git Flow, 2010 von Vincent Driessen vorgeschlagen, definiert zwei permanente Branches und drei Arten temporärer Branches. main enthält ausschließlich Code, der tatsächlich released wurde, jeder Commit auf main entspricht einer Produktionsversion. develop ist der Integrationsbranch, in dem fertige Features zusammenlaufen, bevor ein Release vorbereitet wird. Feature-Branches zweigen von develop ab und werden nach Fertigstellung wieder dorthin gemerged, ihr Lebenszyklus kann sich über Tage oder Wochen erstrecken.

Release-Branches zweigen von develop ab, sobald ein Funktionsumfang für ein Release feststeht. In diesem Branch finden ausschließlich Bugfixes, Versionsnummern-Updates und Dokumentation statt, keine neuen Features mehr. Nach dem Testing wird der Release-Branch sowohl in main als auch zurück in develop gemerged. Hotfix-Branches zweigen direkt von main ab, wenn ein kritischer Produktionsfehler sofort behoben werden muss, und werden ebenfalls in beide permanenten Branches zurückgeführt, damit der Fix nicht beim nächsten regulären Release verloren geht.

Diese Struktur macht Git Flow besonders geeignet für Projekte mit parallel gepflegten Versionen oder festen Release-Fenstern, etwa Softwareprodukte mit mehreren unterstützten Versionen gleichzeitig. Der Preis dafür ist Komplexität: Fünf Branch-Typen mit klaren Merge-Regeln müssen von jedem Teammitglied verstanden und eingehalten werden, sonst verliert das Modell seinen eigentlichen Vorteil.

3. Git Flow in der Praxis: ein kompletter Release-Zyklus

Das git-flow-CLI-Tool, als Erweiterung installierbar, kapselt die Branch-Erstellung und Merge-Logik in einfachen Befehlen wie git flow feature start. Wer ohne dieses Tool arbeitet, was in vielen Teams inzwischen der Standard ist, bildet dieselben Schritte manuell mit regulären git checkout- und git merge-Befehlen nach. Der Ablauf bleibt identisch, nur die Automatisierung fehlt.

Ein typischer Zyklus beginnt mit einem Feature-Branch von develop, läuft über Code-Review und Merge zurück in develop, und mündet schließlich in einen Release-Branch, sobald genug Features für eine Version zusammengekommen sind. Der entscheidende Punkt beim Merge in main: Git Flow verwendet konsequent --no-ff, damit jeder Merge einen eigenen Commit erzeugt und die Feature-Grenzen im Log sichtbar bleiben, selbst wenn ein Fast-Forward-Merge technisch möglich wäre.

#!/usr/bin/env bash
# Git Flow: start a new feature branch from develop
git flow feature start checkout-payment-icons

# Manual equivalent without the git-flow CLI extension
git checkout develop
git pull origin develop
git checkout -b feature/checkout-payment-icons

# Work, commit as usual
git add .
git commit -m "Add payment icon set to checkout"

# Finish: merge back into develop with a merge commit
git flow feature finish checkout-payment-icons

# Manual equivalent, note the --no-ff flag
git checkout develop
git merge --no-ff feature/checkout-payment-icons
git branch -d feature/checkout-payment-icons
git push origin develop

Für ein Magento-Projekt mit mehreren Umgebungen entspricht ein Release-Branch häufig genau einem Staging-Deployment: Der Branch wird auf der Staging-Umgebung getestet, letzte Anpassungen fließen direkt in den Release-Branch, und erst nach Freigabe durch den Kunden erfolgt der Merge nach main und das Produktions-Deployment. Ein Hotfix läuft parallel dazu über einen eigenen, kurzen Branch direkt von main.

#!/usr/bin/env bash
# Git Flow: prepare a release branch from develop
git flow release start 2.4.0

# Manual equivalent
git checkout develop
git checkout -b release/2.4.0

# Only bugfixes and version bumps go into the release branch
git commit -am "Bump version to 2.4.0"

# Finish: merge into main and develop, create a tag
git flow release finish 2.4.0

# Manual equivalent
git checkout main
git merge --no-ff release/2.4.0
git tag -a v2.4.0 -m "Release 2.4.0"
git checkout develop
git merge --no-ff release/2.4.0
git branch -d release/2.4.0
git push origin main develop --tags

# Hotfix: branch directly from main for a critical production bug
git checkout main
git checkout -b hotfix/checkout-crash
git commit -am "Fix null pointer in checkout totals"
git checkout main
git merge --no-ff hotfix/checkout-crash
git tag -a v2.4.1 -m "Hotfix 2.4.1"
git checkout develop
git merge --no-ff hotfix/checkout-crash
git branch -d hotfix/checkout-crash

4. GitHub Flow erklärt: main plus kurzlebige Feature-Branches

GitHub Flow reduziert das Modell auf das Nötigste: einen einzigen permanenten Branch, main, der jederzeit deploybar sein muss, plus kurzlebige Feature-Branches, die direkt von main abzweigen. Es gibt keinen separaten develop-Branch, keine Release-Branches und keine Hotfix-Branches als eigene Kategorie, ein Hotfix ist einfach ein weiterer Feature-Branch mit hoher Priorität.

Die Grundannahme hinter diesem Modell ist Continuous Deployment: Jeder Merge nach main kann, muss aber nicht zwingend, automatisch oder zeitnah live gehen. Das setzt eine belastbare CI/CD-Pipeline voraus, die jeden Merge automatisiert testet, denn es gibt keinen separaten Stabilisierungsschritt wie einen Release-Branch, der Fehler vor dem Produktivsystem abfängt. Qualitätssicherung verlagert sich vollständig in den Pull-Request-Prozess und die automatisierte Testsuite.

Dieses Modell passt hervorragend zu Projekten mit einer einzigen produktiven Version, etwa SaaS-Anwendungen oder Websites ohne parallel unterstützte Versionsstände. Für Magento-Agenturprojekte mit einem einzigen Kunden-Livesystem, das kontinuierlich weiterentwickelt wird, ist genau das häufig der Fall, wodurch GitHub Flow strukturell gut passt, sofern die Testabdeckung ausreichend ist.

5. GitHub Flow in der Praxis: der Pull-Request-Workflow

Der Ablauf ist bewusst kurz: Von main einen beschreibend benannten Branch abzweigen, etwa feature/checkout-payment-icons, lokal committen und regelmäßig pushen, damit der Fortschritt für das Team sichtbar bleibt. Sobald der Branch fertig oder auch nur review-fähig ist, wird ein Pull Request gegen main geöffnet, selbst wenn die Arbeit noch nicht abgeschlossen ist, ein Draft-PR macht den Stand für alle transparent und ermöglicht frühes Feedback.

Automatisierte Checks, PHPStan, PHPCS, Unit-Tests und im Idealfall ein automatisches Deployment auf eine Preview-Umgebung, laufen bei jedem Push in den PR. Erst wenn alle Checks grün sind und mindestens ein Reviewer zugestimmt hat, wird gemerged, in der Regel per Squash-Merge, damit die Historie auf main übersichtlich bleibt. Direkt danach folgt das Deployment, oft vollautomatisch getriggert durch den Merge selbst.

#!/usr/bin/env bash
# GitHub Flow: branch directly from main, keep it short-lived
git checkout main
git pull origin main
git checkout -b feature/checkout-payment-icons

git add .
git commit -m "Add payment icon set to checkout"
git push -u origin feature/checkout-payment-icons

# Open a pull request straight from the CLI
gh pr create \
  --base main \
  --title "Add payment icon set to checkout" \
  --body "Adds icons for the four new payment methods on the checkout page."

Die GitHub-CLI beschleunigt diesen Workflow spürbar: gh pr create und gh pr merge ersetzen den Umweg über die Weboberfläche und lassen sich problemlos in eigene Skripte oder Git-Aliase einbinden, was gerade bei häufigen, kleinen Merges den Unterschied zwischen reibungslosem und mühsamem Alltag ausmacht.

#!/usr/bin/env bash
# GitHub Flow: merge once checks pass and review is approved
gh pr checks 42 --watch
gh pr merge 42 --squash --delete-branch

# Deploy is typically triggered automatically by the merge to main
git checkout main
git pull origin main
# CI/CD pipeline picks up the new commit on main and deploys

6. Entscheidungsfaktor Teamgröße: klein vs. groß

Die Teamgröße ist der stärkste einzelne Prädiktor dafür, welches Modell tatsächlich funktioniert. In einem kleinen Team von zwei bis fünf Entwicklern kennt jeder den Zustand von main aus dem täglichen Stand-up, Kommunikationswege sind kurz, und die zusätzliche Struktur von Git Flow, develop-Branch, Release-Branch, separate Hotfix-Kategorie, erzeugt vor allem Overhead ohne messbaren Sicherheitsgewinn. GitHub Flow passt hier fast immer besser, weil weniger Regeln eingehalten werden müssen und der Weg vom Code zur Produktion kurz bleibt.

In einem großen Team mit zehn oder mehr Entwicklern, mehreren parallelen Feature-Strängen und eventuell mehreren Subteams verändert sich die Rechnung. Ohne einen Integrationsbranch wie develop würde main zum Nadelöhr, an dem sich instabile, halbfertige Features stauen, bevor sie release-reif sind. Git Flow entlastet genau diesen Engpass, indem es Integration und Release-Vorbereitung als eigene, kontrollierte Phasen behandelt, statt alles direkt in den produktiven Branch zu drücken.

Zwischen diesen Extremen gibt es keinen festen Schwellenwert, aber ein brauchbares Faustkriterium: Sobald mehr als ein Reviewer nötig ist, um den Überblick über gleichzeitig laufende Features zu behalten, wird die zusätzliche Struktur von Git Flow tendenziell wertvoller als ihr Overhead.

7. Entscheidungsfaktor Release-Rhythmus: kontinuierlich vs. versioniert

Der zweite entscheidende Faktor ist unabhängig von der Teamgröße: Wie oft und nach welchem Muster geht Code live? Bei Continuous Deployment, mehrere Deployments pro Tag, jeder gemergte PR geht zeitnah live, passt GitHub Flow strukturell, weil es genau für diesen Fall entworfen wurde. Ein separater Release-Branch würde hier nur eine künstliche Verzögerung zwischen fertigem Code und Produktion einbauen, ohne echten Nutzen.

Bei versionierten, geplanten Releases, etwa monatliche Magento-Updates für einen Kunden mit festem Wartungsfenster, oder Software, die in mehreren Versionen parallel unterstützt werden muss, zeigt Git Flow seine Stärke. Der Release-Branch bietet einen klar abgegrenzten Zeitraum für finales Testing, Versionsnummern-Pflege und Abnahme durch den Kunden, ohne dass währenddessen neue, ungetestete Features in denselben Branch einfließen.

Agenturprojekte bewegen sich oft zwischen beiden Polen: Ein Kunde erwartet planbare Release-Termine für sichtbare Änderungen, während im Hintergrund technische Verbesserungen kontinuierlich fließen sollen. Diese Mischsituation ist einer der Hauptgründe, warum reine Lehrbuch-Modelle in der Praxis selten unverändert übernommen werden.

8. Hybride Ansätze für Magento- und Agentur-Projekte

In der Praxis von Magento-Agenturen mit mehreren Umgebungen, lokal, Integration, Staging, Produktion, entsteht häufig eine Mischform: ein schlanker GitHub-Flow-Kern für den täglichen Feature-Fluss, ergänzt um einen langlebigen staging-Branch, der grob der Rolle von develop entspricht. Feature-Branches werden per Pull Request in staging gemerged, dort auf einer echten Umgebung getestet, und erst nach Kundenfreigabe per weiterem PR in main übernommen und deployt.

Ein weiteres verbreitetes Muster ist environment branching: Jeder langlebige Branch, develop, staging, main, entspricht direkt einer Deployment-Umgebung, und ein Merge in den Branch löst automatisiert ein Deployment auf genau diese Umgebung aus. Das kombiniert die Klarheit von Git Flow mit der Deployment-Automatisierung, die GitHub Flow prägt, ohne die vollständige Branch-Taxonomie von develop, feature, release und hotfix übernehmen zu müssen.

#!/usr/bin/env bash
# Hybrid model: environment branches map directly to deployment targets
git checkout staging
git pull origin staging
git merge --no-ff feature/checkout-payment-icons
git push origin staging
# CI deploys "staging" branch pushes straight to the staging environment

# After client approval, promote staging to production
git checkout main
git merge --no-ff staging
git push origin main
# CI deploys "main" branch pushes straight to the production environment

Wichtig ist, diese Hybridmodelle explizit zu dokumentieren, etwa in einer CONTRIBUTING.md, da sie von keinem der beiden Standardmodelle exakt beschrieben werden und neue Teammitglieder sonst falsche Annahmen aus Git-Flow- oder GitHub-Flow-Tutorials übernehmen, die im Projekt so nicht gelten.

9. Praktische Empfehlung: kleines Team vs. großes Team

Für ein kleines Team bis etwa fünf Entwickler mit einem einzigen produktiven Livesystem ist die klare Empfehlung: GitHub Flow, ergänzt um verpflichtende Pull-Request-Reviews und eine automatisierte CI-Pipeline mit PHPStan, PHPCS und Tests. Diese Kombination liefert die Sicherheit, die Git Flow durch Struktur erreicht, ohne dessen organisatorischen Overhead. Ein zusätzlicher staging-Branch für Kundenabnahmen vor dem Live-Deployment ist die einzige sinnvolle Ergänzung in den meisten Agenturprojekten.

Für ein großes Team mit zehn oder mehr Entwicklern, mehreren parallel unterstützten Versionen oder festen Release-Zyklen ist Git Flow, oder ein daran angelehntes Modell mit expliziten Release-Branches, die robustere Wahl. Die zusätzliche Struktur verhindert, dass instabile Features den produktiven Branch destabilisieren, und schafft einen klaren, wiederholbaren Prozess für koordinierte Releases über mehrere Teams hinweg.

Die folgende Tabelle vergleicht beide Modelle entlang der Kriterien, die in der Praxis am häufigsten den Ausschlag geben.

Die Tabelle macht deutlich: Es gibt kein objektiv besseres Modell, nur ein besser oder schlechter passendes für die jeweilige Teamgröße, Release-Kadenz und CI/CD-Reife eines Projekts.

10. Zusammenfassung

Git Flow vs. GitHub Flow ist letztlich keine Frage danach, welches Modell technisch überlegen ist, sondern welches zur Teamgröße, zum Release-Rhythmus und zur CI/CD-Reife eines Projekts passt. Git Flow mit seinen fünf Branch-Typen, develop, feature, release, hotfix und main, bietet Struktur für große Teams, parallel gepflegte Versionen und geplante, versionierte Releases. GitHub Flow mit nur main und kurzlebigen Feature-Branches bietet Geschwindigkeit und Einfachheit für kleine Teams mit Continuous Deployment auf ein einziges Livesystem.

Für die meisten Magento-Agenturprojekte mit kleinen Teams und einem Kunden-Livesystem ist GitHub Flow, ergänzt um einen staging-Branch für Kundenabnahmen, die pragmatischste Wahl. Größere Teams mit mehreren parallel unterstützten Versionen oder festen Wartungsfenstern profitieren dagegen von der zusätzlichen Struktur, die Git Flow bietet. Entscheidend ist am Ende weniger das gewählte Modell selbst, sondern dass das gesamte Team es konsequent und einheitlich anwendet.

11. FAQ: Git Flow vs. GitHub Flow