Git-Branching-Strategien: trunk-basiert, GitHub Flow, Git Flow

Git-Branching-Strategien entscheiden darüber, wie oft man sich gegenseitig blockiert. Die meisten Teams leiden nicht unter zu wenig Struktur, sondern unter zu viel – monatelange Zweige, die am Ende in wochenlangen Zusammenführungen enden.

Die drei Modelle

1) Trunk-basiert (empfohlen fuer die meisten Teams)
   Kurze Zweige (Stunden bis wenige Tage)
   Direkt oder in kleinen Schritten in die Hauptlinie

   main  ----o---o---o---o---o---o---o---o------
              \    /      \  /
               o--o        oo        <- Stunden

   Voraussetzung: Automatische Tests, schnelles Zusammenfuehren.
   Ergebnis: Kein Auseinanderlaufen, keine Konfliktwueste.

2) GitHub Flow
   Ein Zweig je Aenderung, Pull Request, Zusammenfuehren nach main
   main ist immer auslieferbar
   Struktur gering, Prozess ueber den PR

   main  ----o---------o-----------o----------
              \       /    \      /
               o--o--o       o--o--o

   Voraussetzung: Tests, Review, Auslieferung aus main.

3) Git Flow (nur bei Bedarf)
   develop, release/*, hotfix/*, feature/*, main
   Mehrere langlebige Zweige, parallele Versionen

   main     ----o(gross)---------o
                 \             /
   develop  --o---o---o---o---o----o--o--
                \     /    \   /
                 o---o      o-o

   Voraussetzung: starke Disziplin, klare Verantwortlichkeiten.
   Passt bei: Versionierter Software mit Supportlinien
   (nicht bei staendiger Auslieferung!).

Was wann passt

Kontinuierliche Auslieferung eines Webdienstes: Trunk-basiert. Fertig.
Team mit Reviewprozess aber ohne Zwischenzweig: GitHub Flow.
Software mit mehreren unterstützten Versionen (etwa eine Bibliothek): Git Flow oder zumindest Versionszweige.
Regulierte Umgebung mit Nachweisbedarf: GitHub Flow mit verpflichtendem PR und signierten Commits.

Praxis: kurz und sauber arbeiten

# Aktuellen Stand holen und Zweig anlegen
git switch main
git pull --ff-only                  # nur vorspielen, nie erzwungen
git switch -c fix/session-timeout

# Kleine, zusammenhaengende Commits
git add -p                          # stueckweise, kein "git add ."
git commit -m "fix: Sitzung nach 30 Minuten Inaktivitaet beenden"

# Aktuelle Aenderungen der Hauptlinie einbeziehen
git fetch origin
git rebase origin/main              # lineare Geschichte, keine Konfliktwolke
#   Rebase NUR auf eigenen Zweigen, NIE auf veroeffentlichten!
#   Wer geteilte Zweige rebased, zwingt anderen die Historie auf.

# Bei Konflikten:
git status                          # welche Dateien?
#   Datei bearbeiten, dann:
git add 
git rebase --continue
git rebase --abort                  # Abbruch: zurueck zum Ausgangspunkt

# Zweig aktualisieren und zusammenfuehren
git switch main
git merge --no-ff fix/session-timeout    # oder --ff-only je Regel

# Zweig loeschen
git branch -d fix/session-timeout
git push origin --delete fix/session-timeout

Regeln, die Ärger verhindern

# 1) Keine erzwungenen Vorgaenge auf geteilte Zweige
git push --force-with-lease           # wenn ueberhaupt: leasend
#   --force-with-lease schlaegt fehl, wenn jemand anderes
#   in der Zwischenzeit gepusht hat. --force nicht verwenden!

# 2) Hauptlinie schuetzen (serverseitig erzwingen!)
#    - Zusammenfuehren nur per Pull Request
#    - Tests muessen gruen sein
#    - Mindestens eine Pruefung durch einen Menschen
#    - Keine erzwungenen Vorgaenge
#    - Signierte Commits

# 3) Zweignamen nach Konvention
#    fix/..., feature/..., chore/..., docs/...
#    Mit Ticketnummer: fix/1234-session-timeout

# 4) Commit-Nachrichten, die man spaeter versteht
#    "fix: Sitzung nach Inaktivitaet beenden"
#    Typen: feat, fix, docs, style, refactor, perf, test, chore
#    Konventionelle Commits erlauben automatische Protokolle.

# 5) Kleine Zweige
#    Faustregel: Ein Zweig sollte selten aelter als zwei Tage sein.
#    Aeltere Zweige zusammenfuehren oder verwerfen - nicht retten.

# 6) Nie auf main direkt arbeiten
#    Serverseitig verbieten, nicht nur vereinbaren.

# 7) Regelmaessig aufraeumen
git branch --merged main | grep -v main | xargs -r git branch -d
git fetch --prune                     # geloeschte Zweige entfernen

Prüfliste

Ist die Hauptlinie serverseitig geschützt (keine direkten Pushes)?
Laufen Tests automatisch bei jedem Pull Request?
Ist die durchschnittliche Lebensdauer eines Zweigs unter zwei Tagen?
Wird Rebase nur auf eigenen, nicht veröffentlichten Zweigen genutzt?
Sind Commit-Nachrichten aussagekräftig (Grund, nicht Vorgang)?
Sind Commits signiert, wenn Nachvollziehbarkeit gefordert ist?
Gibt es eine Regel für Notfallkorrekturen in Produktion?
Ist bekannt, wie ein fehlerhaftes Zusammenführen rückgängig gemacht wird?

Häufige Fehler

Zu langlebige Zweige. Nach drei Wochen ist die Zusammenführung ein eigenes Projekt. Der häufigste und teuerste Fehler.
git push --force auf geteilte Zweige. Die Arbeit anderer wird überschrieben. --force-with-lease verwenden und geteilte Zweige möglichst nicht umschreiben.
Rebase auf veröffentlichten Zweigen. Andere bauen auf Commits auf, die verschwinden – Chaos beim nächsten Abruf.
Git Flow ohne Bedarf. Vier Zweigtypen, die gepflegt werden müssen, ohne dass die Auslieferung schneller wird.
Keine Servervorgaben. Regeln, die nur vereinbart sind, werden bei Termindruck gebrochen. Die Plattform muss sie erzwingen.
Pull Requests mit 3.000 Zeilen. Niemand prüft so etwas sinnvoll. Kleine Änderungen sind die Voraussetzung für echte Prüfung.
Zusammenführen ohne Tests. Ein grüner Build ist nicht optional – er ist der Grund, warum Trunk-basiert funktioniert.
Konflikte „schnell“ lösen. Ein falsch aufgelöster Konflikt ist ein versteckter Fehler. Nach dem Zusammenführen bauen und testen.

Verwandte Grundlagen: Git, Git-Branching, Git-Befehle, CI/CD.

Webentwicklung