Git-Workflows: Feature Branch, Gitflow, Trunk-Based

Du kennst Branches, Merges, Rebases – die Bausteine. Aber wie nutzt ein Team sie systematisch? Es haben sich verschiedene Workflows etabliert. Diese Lektion vergleicht die drei wichtigsten: Feature Branch (GitHub Flow), Gitflow, und Trunk-Based Development. Jeder hat seine Stärken – die richtige Wahl hängt vom Projekt ab.

Ein „Workflow" ist nicht zwingend – Git zwingt keinen vor. Es sind Konventionen, die ein Team treffen sollte, damit alle nach demselben Muster arbeiten. Falsch gewählt: viel Reibung. Richtig gewählt: alles flutscht.

1) Die drei Hauptworkflows – interaktiv

Klick durch die drei Workflows und sieh, wie sie strukturell unterscheiden:

2) Feature Branch Workflow (GitHub Flow)

Der einfachste und heute meistgenutzte Workflow. Nur ein Hauptbranch main, der immer deploybar ist. Alles andere sind kurzlebige Branches:

3) Gitflow – die strukturierte Variante

2010 von Vincent Driessen erfunden. Sehr formal, mit mehreren parallelen Hauptbranches. Heute oft als „zu komplex" für moderne Web-Projekte angesehen, aber in Enterprise-Umgebungen mit klassischen Releases (jedes Quartal eine Version) weiterhin sinnvoll.

Branches:

• main – Production-Code, jedes Commit ist ein Release.
• develop – Sammel-Branch für nächste Release.
• feature/... – einzelne Features, mergen in develop.
• release/v1.2 – Vorbereitung eines Releases. Nur Bugfixes, keine neuen Features.
• hotfix/... – schnelle Production-Fixes, direkt von main, gehen zurück in main + develop.

4) Trunk-Based Development

Der radikale Workflow: alle Entwickler:innen commiten direkt in main (= „Trunk"). Branches existieren kaum oder leben nur Stunden. Klingt verrückt, ist aber bei Google, Facebook und vielen Hochleistungs-Teams Standard.

5) Direktvergleich

6) Welcher Workflow für welches Projekt?

7) Release-Strategien

Ein Workflow allein reicht nicht – wie kommt der Code zum User? Drei Modelle:

• Continuous Deployment: jeder Merge in main geht automatisch live. Maximale Geschwindigkeit, erfordert exzellente Tests.
• Continuous Delivery: jeder Merge ist deploy-bereit, aber Auslösung manuell („Deploy"-Button). Sicherer als CD.
• Release-Cycles: klassisch versioniert – Releases zu festen Zeitpunkten (jedes Quartal v1.2, v1.3, ...). Passt zu Gitflow.

Im Rahmen von DORA-Metriken (Deployment Frequency, Lead Time, Mean Time to Restore, Change Failure Rate) gilt: Elite-Teams deployen mehrmals täglich, schlechte Teams einmal im Monat. Mehr in K55 (CI/CD).

8) Branch Protection Rules

Egal welcher Workflow – moderne Plattformen bieten Branch Protection, um den Workflow technisch zu erzwingen:

• Direct push deaktivieren: niemand darf direkt auf main pushen, nur über PRs.
• Required reviews: mindestens 1-2 Approvals nötig vor Merge.
• CI muss grün sein: Tests, Lints, Build müssen erfolgreich sein.
• Up-to-date Branch: der PR-Branch muss aktuelle main-Änderungen enthalten.
• Linear history erzwingen: nur Rebase/Squash erlauben, keine Merge-Commits.
• Signed commits: nur kryptographisch signierte Commits.

Konfiguration auf GitHub: Settings → Branches → Branch protection rules. Auf GitLab: Settings → Repository → Protected branches.

9) Praxis-Beispiel: Feature-Branch im Detail

So sieht ein typischer Feature-Branch-Workflow konkret aus, von Anfang bis Ende:

# Tag 1: Branch erstellen
git switch main
git pull
git switch -c feature/payment-stripe

# Tag 1-3: Arbeiten
# (Code schreiben, Tests laufen lassen)
git add .
git commit -m "feat: Stripe-Integration vorbereiten"
git commit -m "feat: Stripe-Webhook-Handler"
git commit -m "test: Stripe-Service abdecken"

# Tag 3: Push und PR
git push -u origin feature/payment-stripe
# → Auf GitHub: PR öffnen, Reviewer auswählen

# Tag 4: Review-Feedback einarbeiten
git add .
git commit -m "fix: Review-Feedback adressiert"
git push

# Tag 4-5: Falls main weitergegangen ist
git fetch origin
git rebase origin/main
git push --force-with-lease

# Tag 5: Approval, dann auf GitHub mergen (Squash)
# → Branch wird gelöscht
git switch main
git pull
git branch -d feature/payment-stripe

Dieser Zyklus dauert typischerweise 1-5 Tage. Längere Zyklen sind ein Warnzeichen – das Feature ist zu groß. Aufteilen!

10) Fork-Modell für Open Source

Eine Variante des Feature Branch für externe Contributors:

1. Repository auf GitHub forken (eigene Kopie).
2. Fork lokal clonen.
3. Feature-Branch auf deinem Fork.
4. PR vom Fork gegen Original-Repo (upstream).
5. Maintainer reviewt und mergt.

Vorteil: jeder kann beitragen, ohne Schreibrechte auf das Original-Repo. Standard bei großen Open-Source-Projekten (Linux Kernel, React, Vue, ...).

Zusammenfassung

Drei Haupt-Workflows: Feature Branch (GitHub Flow): nur main + kurzlebige Branches, PR pro Feature – einfach, modern, Standard für Web/SaaS. Gitflow: main + develop + release/feature/hotfix-Branches – strukturiert, für versionierte Releases (Mobile, Enterprise). Trunk-Based Development: alle direkt in main, Feature Flags – maximaler Speed, hohe Anforderungen an Tests. Branch Protection Rules erzwingen den Workflow technisch. Open-Source-Variante: Fork + PR gegen upstream. Nächste Lektion: Pull Requests und Code Reviews.