Git Flow, GitHub Flow und Trunk-Based: welcher Git-Workflow passt?

Was ist ein Git-Workflow und warum ist die Wahl wichtig?

Ein Git-Workflow ist die Vereinbarung im Team darüber, welche Branches es gibt, wovon sie abzweigen, wohin sie gemergt werden und was als releasefertig gilt. Git selbst schreibt davon nichts vor. Ohne Vereinbarung arbeitet also jeder auf seine Art, und nach einem Monat liegen Dutzende Branches im Repository, niemand weiß, was deployt ist, und Merges werden zu stundenlangen Konflikten.

Die bekanntesten Modelle sind Git Flow, GitHub Flow (eine Variante des Feature Branch Workflow) und Trunk-Based Development. Es geht dabei nicht um „alt gegen neu“, sondern um Werkzeuge für unterschiedliche Bedingungen: wie oft Sie releasen, wie viele Produktversionen Sie gleichzeitig pflegen und wie gut Ihre automatisierten Tests sind.

Git Flow: das Modell mit develop- und release-Branches

Git Flow wurde 2010 von Vincent Driessen beschrieben. Das Modell beruht auf zwei langlebigen Branches:

• main (in älteren Projekten master) – nur veröffentlichter Code; jeder Commit hier entspricht einem Release und bekommt ein Tag;
• develop – der Integrationsbranch, in den fertige Features für das nächste Release gemergt werden.

Dazu kommen drei Arten temporärer Branches:

Git Flow mit reinem Git

Der Zyklus eines Features und eines Releases sieht so aus:

# Feature
git switch develop
git switch -c feature/cart-discounts
# ... Commits ...
git switch develop
git merge --no-ff feature/cart-discounts
git branch -d feature/cart-discounts

# Release
git switch -c release/1.4.0 develop
# ... Versionsanpassungen und Bugfixes ...
git switch main
git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop
git merge --no-ff release/1.4.0
git branch -d release/1.4.0

Das Flag --no-ff ist für dieses Modell entscheidend: Es erzeugt auch dort einen Merge-Commit, wo ein Fast-Forward möglich wäre, sodass in der Historie sichtbar bleibt, welche Commits zu einem Feature oder Release gehörten.

Die Erweiterung git-flow

Damit Sie diese Befehlsfolgen nicht von Hand tippen müssen, gibt es das Tool git-flow (heute installiert man meist einen gepflegten Fork, in Paketmanagern heißt er oft git-flow-avh). Es fügt Unterbefehle hinzu:

git flow init -d
git flow feature start cart-discounts
git flow feature finish cart-discounts
git flow release start 1.4.0
git flow release finish 1.4.0
git flow hotfix start 1.4.1
git flow hotfix finish 1.4.1

git flow init fragt nach den Namen der Branches und Präfixe (mit -d übernimmt es die Standardwerte), und die finish-Befehle führen alle nötigen Merges aus, setzen das Tag und löschen den temporären Branch. Auch viele Git-GUI-Clients unterstützen Git Flow per Button.

Vor- und Nachteile von Git Flow

Vorteile: klare Struktur, eindeutiger Status des Codes (main ist das, was Kunden haben; develop die nächste Version), eine eigene Stabilisierungsphase vor dem Release und bequeme Pflege von Hotfixes. Das passt gut zu Mobile-Apps, Standardsoftware, Bibliotheken und Firmware – überall dort, wo ein Release ein App-Store-Review durchläuft oder beim Kunden installiert wird.

Nachteile: viele Branches und Merges, langlebige Feature-Branches entfernen sich immer weiter von develop, und die doppelten Merges von release und hotfix vergisst man leicht. Für einen Webdienst, der mehrmals täglich deployt wird, werden release-Branches zur Bürokratie. Der Autor des Modells hat seinem Artikel 2020 selbst einen Hinweis hinzugefügt: Für kontinuierlich ausgelieferte Software sollte man sich einfachere Ansätze wie GitHub Flow ansehen.

GitHub Flow: kurze Branches und Pull Requests

GitHub Flow ist eine schlanke Version des Feature Branch Workflow. Die Regeln passen in wenige Punkte:

1. main ist immer lauffähig und bereit zum Deployment.
2. Jede Arbeit passiert in einem Branch von main mit sprechendem Namen.
3. Der Branch wird regelmäßig gepusht, und für die Diskussion wird ein Pull Request (Merge Request) geöffnet.
4. Nach Review und grüner CI wird der Branch in main gemergt.
5. Was in main gemergt ist, wird sofort deployt.

git switch main
git pull
git switch -c feature/new-payment
# ... Commits mit verständlichen Nachrichten ...
git push -u origin feature/new-payment
# Pull Request öffnen, Review und CI durchlaufen, in main mergen

Vorteile: ein einziger langlebiger Branch, minimale Regeln, ein schneller Weg von der Idee in die Produktion, natürliches Code-Review. Nachteile: Es gibt keinen eingebauten Platz für die Pflege mehrerer Versionen oder eine Stabilisierung vor dem Release, und ohne gute automatisierte Tests bleibt „main ist immer bereit“ ein frommer Wunsch.

Einen ähnlichen Ansatz mit zusätzlichen Umgebungs-Branches (etwa staging und production) nennt man manchmal GitLab Flow. Er ist nützlich, wenn das Deployment in die Produktion nicht sofort erfolgt, sondern nach Zeitplan oder nach manueller Prüfung.

Trunk-Based Development

Beim Trunk-Based Development integrieren alle Entwickler ihre Änderungen häufig – mindestens einmal am Tag – in einen einzigen Branch (den Trunk, also main). Wenn es überhaupt Branches gibt, leben sie Stunden statt Wochen. Unfertige Funktionen landen zwar in main, sind aber hinter einem Feature Flag versteckt:

if (featureFlags.isEnabled("new-checkout", user)) {
    renderNewCheckout();
} else {
    renderOldCheckout();
}

Der Hauptvorteil: schwere Konflikte bleiben fast vollständig aus, weil die Änderungen klein sind und gemergt werden, solange alle noch den Kontext im Kopf haben. Das Modell ermöglicht Continuous Integration im wörtlichen Sinn und eignet sich für erfahrene Teams mit schneller CI und hoher Testabdeckung. Release-Branches sind erlaubt, werden aber erst unmittelbar vor der Veröffentlichung vom Trunk abgezweigt; Korrekturen gehen zuerst in den Trunk und werden dann per Cherry-Pick übertragen.

Nachteile: Sie brauchen Disziplin und Infrastruktur – schnelle Tests, Flags, Monitoring. Einsteiger trauen sich nicht, täglich nach main zu committen, und eine schwache CI macht den Trunk zu einem dauerhaft kaputten Branch. Auch Flags müssen rechtzeitig entfernt werden, sonst wuchert der Code mit toten Verzweigungen zu.

Git Flow, GitHub Flow und Trunk-Based im Vergleich

So wählen Sie den Git-Workflow für Ihr Team

Beantworten Sie ein paar Fragen:

• Müssen mehrere veröffentlichte Versionen gepflegt werden? Nutzen Kunden 2.x und 3.x und brauchen beide Korrekturen – Git Flow oder Trunk-Based mit release-Branches.
• Wie oft deployen Sie? Einmal im Quartal – dann stört Git Flow nicht. Jeden Tag – wählen Sie GitHub Flow oder Trunk-Based.
• Wie sehr vertrauen Sie Ihren Tests? Ist die CI langsam und die Abdeckung schwach, starten Sie mit GitHub Flow mit Pflicht-Review und verkürzen Sie die Branches schrittweise.
• Wie groß und erfahren ist das Team? Für kleine Teams und Einsteiger ist GitHub Flow am einfachsten: eine Regel „main ist immer lauffähig“ und ein Pull Request für alles.

Praktischer Rat: Wählen Sie Git Flow nicht, „weil man das so macht“. Beginnen Sie mit dem einfachsten Prozess, der Ihre Aufgaben löst, und machen Sie ihn erst komplexer, wenn ein konkretes Problem auftaucht – etwa wenn Sie eine Stabilisierungsphase oder die Pflege alter Versionen brauchen.

Regeln, die in jedem Workflow funktionieren

• Schützen Sie main auf dem Server: kein direkter Push, Pflicht-Reviews und grüne CI vor dem Merge.
• Einigen Sie sich auf Branch-Namen: feature/, fix/, hotfix/ plus Ticketnummer.
• Halten Sie Branches kurz: Je länger ein Branch lebt, desto schmerzhafter der Merge. Holen Sie main regelmäßig per Merge oder Rebase in Ihren Branch.
• Wählen Sie eine Merge-Strategie für Pull Requests (Merge-Commit, Squash oder Rebase) und wenden Sie sie einheitlich an.
• Markieren Sie Releases mit annotierten Tags nach Semantic Versioning.

Hotfix in jedem Modell: ein Bug, drei Prozesse

Der Unterschied zwischen den Ansätzen zeigt sich am besten bei einer dringenden Korrektur in der Produktion.

In Git Flow wird hotfix/1.4.1 von main erstellt; nach der Korrektur wird der Branch mit dem Tag v1.4.1 in main gemergt und unbedingt auch in develop (oder in den aktuellen release-Branch, falls es einen gibt). Der vergessene zweite Merge ist ein klassischer Fehler: Im nächsten Release „kehrt“ der Bug zurück.

git switch -c hotfix/1.4.1 main
git commit -am "Rabattberechnung korrigieren"
git switch main && git merge --no-ff hotfix/1.4.1
git tag -a v1.4.1 -m "Hotfix 1.4.1"
git switch develop && git merge --no-ff hotfix/1.4.1

In GitHub Flow ist ein Hotfix ein gewöhnlicher kurzer Branch von main mit Pull Request, der im Review Vorrang bekommt. Nach dem Merge geht er mit demselben automatischen Deployment in die Produktion – einen separaten Prozess gibt es nicht.

Beim Trunk-Based Development wird die Korrektur zuerst in den Trunk committet; läuft in der Produktion ein release-Branch, wird der Commit per git cherry-pick -x <hash> dorthin übertragen. Das Flag -x fügt der Nachricht einen Verweis auf den Original-Commit hinzu, damit der Zusammenhang in der Historie sichtbar ist. Liegt das Problem in einer neuen Funktion, reicht es oft, deren Feature Flag abzuschalten, ohne den Code überhaupt anzufassen.

Im Vorstellungsgespräch: „Welchen Git-Workflow haben Sie verwendet?“

Der Interviewer prüft nicht, ob Sie die Namen kennen, sondern ob Sie die Kompromisse verstehen. Eine gute Antwort nennt das Modell, beschreibt, wie Branches und Reviews darin organisiert sind, und erklärt, warum es zum Projekt passte. Zum Beispiel: „Wir haben GitHub Flow genutzt: Branches von main, Pull Requests mit Pflicht-Review und CI, nach dem Merge automatisches Deployment. Git Flow haben wir nicht gewählt, weil wir mehrmals pro Woche released haben und release-Branches uns nur gebremst hätten.“ Pluspunkt: erzählen, was Sie ändern würden, wenn der Prozess wächst.

Fazit

Git Flow ist ein strenges Modell mit develop-, release- und hotfix-Branches, gut für Produkte mit geplanten Versionen und der Pflege mehrerer Releases. GitHub Flow ist einfacher und passt zu den meisten Webprojekten, während Trunk-Based Development maximale Geschwindigkeit bietet, aber eine ausgereifte CI und Feature Flags verlangt. Wählen Sie Ihren Git-Workflow nach Release-Häufigkeit und Testqualität, nicht nach Mode. Alle drei Ansätze mit ihren Befehlen und typischen Fehlern üben wir praktisch im Git-Kurs.