Git-Workflows, die im Team wirklich funktionieren

Trunk-based Development, Git Flow oder etwas Eigenes? Nach fünf Jahren in verschiedenen Teams habe ich eine klare Meinung — und ein paar Regeln, die sich bewährt haben.

Warum Git Flow in den meisten Teams scheitert

Git Flow wurde 2010 von Vincent Driessen vorgestellt — für eine Welt, in der Releases alle paar Monate stattfinden. In modernen Teams mit wöchentlichen Deployments ist das Modell überkomplex.

Was stattdessen funktioniert

Trunk-based Development mit kurzen Feature-Branches. Faustregel: Branches leben nie länger als zwei Tage.

git checkout -b feature/login-redirect
# ... Arbeit ...
git rebase main
git push origin feature/login-redirect

Drei Regeln, die sich bewährt haben

1. Kleine Commits. Lieber zehn kleine als ein großer. Reviews werden einfacher, Reverts auch.

2. Feature Flags statt langer Branches. Code kann in main landen, ohne aktiv zu sein.

3. Kein Merge-Commit-Gefrickel. Rebase statt Merge, wo es geht.

Fazit

Es gibt keinen universellen Workflow. Aber die Regel „je kürzer der Branch, desto besser" hat sich in allen Teams bewährt, in denen ich war.