Feature Branches vs Trunk Based Development, wie entwickelt ihr?

In verschiedenen Projekten habe ich zwei sehr unterschiedliche Muster erlebt, wie unfertige Features entwickelt werden.
1) Starkes Feature Branching (Gitflow etc) Man arbeitet in einer Kopie des Codes, bis „alles fertig“ ist und merged dann, oft erst nach QA und diversen Qualitätschecks. In der Praxis wird das mit mehreren Entwicklern schnell teuer: - Je länger ein Branch lebt, desto wahrscheinlicher und schmerzhafter werden Merge Konflikte, besonders wenn parallel an denselben Dateien gearbeitet wird. - Zwei Features in getrennten Branches werden einzeln getestet, aber nie im Zusammenspiel. Erst beim Zusammenführen sieht man, ob A und B zusammen funktionieren. - Deployments werden zu großen Events: komplex, fehleranfällig, extrem aufwendig. Ein Verhaltenseffekt, den ich beobachtet habe: Wenn vor dem Merge sowieso QA wartet, wird das eigene Testing manchmal nachlässiger, weil „QA findet’s schon“.
2) Trunk Based Development + Continuous Integration Hier minimiert man die Zeit, in der mehrere Code Versionen parallel existieren. Ziel ist häufiges Integrieren in den Trunk, idealerweise mindestens täglich, mit möglichst viel automatisiertem Testing auf dem integrierten Stand. Das erzwingt ein Umdenken: kleinere Änderungen, schnellere Feedback Loops, weniger Reibungsverluste durch lange Divergenz.
Wie arbeitet ihr, eher Feature Branching oder Trunk Based? Und was war bei euch der Hauptgrund für die Entscheidung?
Mehr Einblicke
Im Blog finden Sie weitere Praxiserfahrungen aus Projekten.