Die Frage Trunk Based Development vs Feature Branch führt in vielen Teams zu einer falschen Debatte. Diskutiert wird über Namen, Git-Diagramme und persönliche Vorlieben, obwohl der eigentliche Unterschied viel einfacher ist. Entscheidend ist, ob Entwicklerinnen und Entwickler ihre Arbeit in kleine, integrierbare Einheiten zerlegen und diese schnell wieder in einen gemeinsamen Stand zurückführen, oder ob sie Änderungen über längere Zeit isoliert ansammeln. Wer diese Unterscheidung versteht, kann beide Modelle nüchtern beurteilen, statt einem Etikett zu folgen.

Trunk Based Development vs Feature Branch auf einen Blick

Nicht der Name des Workflows zählt, sondern ob Änderungen klein genug sind, um mindestens täglich in den gemeinsamen Hauptzweig zu fließen. Bei Trunk-Based Development zerlegen Entwickler ihre Arbeit in kleine Einheiten und führen sie mindestens einmal täglich, potenziell sogar mehrfach täglich, in den Trunk zurück. Beim Feature-Branching arbeitet dagegen jemand isoliert weiter, bis eine Funktion fertig ist, und merged sie erst danach.

Die DORA-Auswertung zu Trunk-Based Development der Daten aus den Jahren 2016 und 2017 identifizierte drei messbare Leitplanken für leistungsfähigere Teams, höchstens drei aktive Branches im Repository, tägliches Mergen in den Trunk sowie den Verzicht auf Code-Freeze- und separate Integrationsphasen. Diese Zahlen stützen keine Dogmatik. Sie zeigen, welche Größen ein Team überhaupt steuern kann.

Die Tabelle als Arbeitsinstrument lesen

Lesen Sie die Tabelle zeilenweise als Prüfliste für Ihre Lage, nicht als Punktesystem. Wo Ihr Team bei Integrationsfrequenz, Branch-Lebensdauer und CI-Anspruch heute steht, entscheidet mehr als Ihre bevorzugte Bezeichnung.

Ein kurzlebiger Feature-Branch, der noch am selben Tag mit dem Trunk synchronisiert und zurückgeführt wird, liegt praktisch nah an Trunk-Based Development. Ein Branch, der wochenlang ohne Abgleich weiterläuft, tut das nicht, auch wenn an seinem Ende eine Pipeline wartet. Der Unterschied entsteht durch die Zeit bis zur Integration.

Eine einfache Leseanweisung

Verwirrend wird es oft, weil Teams kurze Branches und Trunk-Arbeit als Gegensätze behandeln. Ein Beispiel löst das auf. Eine Entwicklerin baut morgens einen kleinen API-Schritt, testet ihn, merged ihn mittags hinter einem ausgeschalteten Feature Flag und setzt nachmittags die Oberfläche darauf. Ob der Zwischenstand eine Stunde auf einem eigenen Branch lag, ist zweitrangig.

Fehlen automatisierte Tests oder ein immer baubarer Hauptzweig, bleibt das Team beim kurzen Feature-Branch und baut zuerst diese Grundlage, statt nur die Bezeichnung zu wechseln.

Arbeitsablauf von Trunk und Feature Branch

Der Trunk ist der einzige langlebige Integrationszweig. Kurzlebige Arbeitsstände gehen von ihm ab und fließen noch am selben Tag dorthin zurück. Dadurch sehen alle Beteiligten laufend denselben Codezustand.

Ein typischer Tag auf dem Trunk

Morgens zieht ein Entwickler den aktuellen Trunk und schneidet seine Aufgabe so zu, dass der erste Schritt allein baubar ist. Er schreibt kleine Commits, lässt lokale Tests laufen und merged den ersten Schritt noch vor dem Mittagessen. Die Pipeline prüft den gemeinsamen Stand, ein kurzes Review betrachtet nur dieses kleine Diff.

Nachmittags folgt der zweite Schritt auf derselben Grundlage. Die neue Funktion bleibt per Flag ausgeschaltet, weil sie fachlich noch nicht fertig ist. Der Trunk muss deshalb rückwärtskompatibel bleiben, denn unfertige Pfade liegen bereits im gemeinsamen Code. Alte und neue Logik dürfen nebeneinander funktionieren, bis das Flag den neuen Pfad freischaltet.

Wer Reviews in so kleinen Einheiten organisiert, profitiert von klaren Erwartungen an Diff-Größe und Reaktionszeit, wie sie in praktischen Regeln für bessere Code-Reviews beschrieben werden. Das Review wird zur laufenden Abstimmung statt zur Endabnahme.

Ein typischer Tag auf einem Feature-Branch

Auf einem Feature-Branch startet die Arbeit ebenfalls vom aktuellen Hauptstand. Danach entfernt sich der Ablauf. Die Entwicklung läuft weiter, bis die Funktion fachlich fertig wirkt, erst dann entsteht ein Pull Request mit Review und Merge.

Die Divergenz entsteht leise dazwischen. Läuft der Branch Tage oder Wochen ohne Synchronisation, ändern Kolleginnen und Kollegen parallel dieselben Module im Hauptzweig. Beim Merge treffen dann nicht nur zwei Codezustände aufeinander, sondern auch Entscheidungen, die ohne gegenseitige Kenntnis gefallen sind. Konflikte in Git zeigen nur die sichtbare Hälfte dieses Problems.

• Commit-Größe prüfen: Lässt sich die Änderung in wenigen Minuten nachvollziehen?
• Offene Branches zählen: Wie viele Arbeitsstände laufen heute parallel?
• Letzte Synchronisation notieren: Wann hat der Branch zuletzt den Hauptstand aufgenommen?

Gitflow gehört als verwandtes, schwereres Muster daneben, mit zusätzlichen Release- und Hotfix-Zweigen. Es ist hier keine dritte gleichwertige Option, sondern ein Hinweis darauf, dass mehr Zweige mehr Pflege brauchen.

Ein Feature-Branch mit täglichem Rebase oder Merge aus dem Trunk steht dem Trunk-Mechanismus näher als ein wochenlanger Branch mit einer CI-Pipeline erst am Ende. Der Alltag entscheidet, nicht die Zeichnung im Handbuch.

Auswirkungen auf CI CD Testing und Reviews

Continuous Integration meint die Häufigkeit der Zusammenführung, nicht nur eine vorhandene Pipeline. Ein Team mit nächtlichen Builds, das Branches mehrere Tage offen hält, automatisiert zwar seine Builds, integriert aber spät. Genau an dieser Stelle verwechseln viele Teams Werkzeug und Arbeitsweise.

Die DORA-Darstellung zu Continuous Integration beschreibt, dass Teams bessere Softwarebereitstellungs- und Betriebsleistungen erzielen, wenn Entwickler ihre Änderungen mindestens täglich in den Trunk integrieren, statt langfristige Feature-Branches zu pflegen. Kleine, in sich geschlossene Änderungen verkürzen die Feedbackschleife. Sie reduzieren auch die Menge an Code, die gleichzeitig zusammengeführt werden muss.

Was Continuous Integration im Kern ausmacht, lässt sich daran testen, ob ein Merge noch am selben Tag ein verwertbares Ergebnis liefert. Kommt das Feedback erst nach Tagen, arbeiten alle auf veränderter Grundlage weiter.

Was der Trunk von Pipeline und Tests verlangt

Eine belastbare Trunk-Praxis beruht auf wenigen, strengen Regeln. Der Trunk bleibt grün, Tests laufen bei jedem Merge, und ein fehlgeschlagener Build hat Vorrang vor neuer Arbeit. Niemand schiebt weitere Änderungen auf einen roten Stand, weil sonst niemand mehr weiß, welcher Commit den Fehler eingeführt hat.

• Schnelle Schicht auf jedem Commit: Unit-Tests und Vertragstests geben in Minuten Rückmeldung zu Logik und Schnittstellen.
• Integrationsprüfungen nahe am Merge: Etwas langsamere Tests laufen vor oder direkt nach der Zusammenführung und prüfen Zusammenspiel und Persistenz.
• Manuelle Abnahme gezielt einsetzen: Menschen prüfen vor allem das, was ein Feature Flag später für Nutzer sichtbar schaltet.

Kleine Änderungen machen Fehler eng eingrenzbar. Sagt die Pipeline nach einem Diff von wenigen Dateien Rot, ist die Ursache meist schnell gefunden. Nach einem Merge mit hunderten Dateien beginnt erst die Suche.

Review ist eine Größenfrage

Code-Review scheitert selten am Willen, oft an der Diff-Größe. Ein kleines, abgeschlossenes Paket lässt sich innerhalb von Stunden ernsthaft lesen. Ein Pull Request nach zwei Wochen Arbeit zwingt Reviewer dagegen, Architektur, Logik und Details gleichzeitig zu prüfen.

Deshalb ersetzen manche Teams lange Pull Requests durch Pair-Reviews oder kurze synchrone Durchsichten direkt nach dem Commit. Andere behalten Pull Requests, begrenzen aber ihre Größe und vereinbaren eine Reaktionszeit in Stunden. Beide Wege funktionieren, solange niemand tagelang auf Freigaben wartet.

Feature Flags sind Voraussetzung

Ohne Feature Flags müsste unfertige Arbeit draußen bleiben, bis sie nutzbar ist. Mit Flags liegt sie im Trunk, bleibt für Nutzer ausgeschaltet und lässt sich ohne Redeploy wieder abschalten. Das trennt Deployment von Aktivierung, was viele Diskussionen rund um Trunk Based Development vs Feature Branch vereinfacht.

Flags sind jedoch Betriebscode, kein Beiwerk. Jedes Flag braucht einen Eigentümer, einen Zweck und ein Ablaufdatum. Bleibt es dauerhaft bestehen, verzweigt es den Code an vielen Stellen und erzeugt genau die Unübersichtlichkeit, die kurze Branches vermeiden sollten. Die Falle ist selten das fehlende Flag, sie ist das vergessene Flag.

Für einen Feature-Branch ist die Branch-Lebensdauer die entscheidende Steuerungsgröße, nicht die Existenz von Pull Requests.

Teamgröße Release-Management und Kapazität

Die Modellwahl hat in Deutschland einen handfesten Kapazitätskontext. Die Fraunhofer-Untersuchung zur Softwareentwicklung in Deutschland ermittelte einen unmittelbaren Fehlbedarf von 28.000 Softwareentwicklern sowie einen Bedarf von 55.000 zusätzlichen Entwicklern innerhalb der folgenden zwölf Monate. Diese Zahlen messen keine Workflow-Nutzung, sie zeigen, warum späte Integrationsarbeit für knappe Teams besonders teuer ist.

Kleine Teams sind nicht automatisch frei von Merge-Kosten

Ein Team mit zwei bis sechs Personen überblickt lange Branches oft noch persönlich. Wer arbeitet gerade woran, lässt sich in einem kurzen Gespräch klären. Teuer wird es, sobald zwei Personen parallel dasselbe Modul verändern, etwa die Preislogik in einem Shop oder die Berechtigungsprüfung in einem SaaS-Produkt.

Bei verteilten oder internationalen Teams steigt der Aufwand weiter. Ein großes Diff wartet über Zeitzonen hinweg auf Review, Rückfragen verlieren jeweils einen Arbeitstag, und der Branch entfernt sich während dieser Wartezeit weiter vom Hauptstand. Kleinere Lieferpakete entlasten hier stärker als ein zusätzliches Abstimmungstreffen.

Release-Management getrennt vom Branching denken

Ein häufiger Denkfehler lautet, ein geplantes Release erzwinge lange Feature-Branches. Das stimmt nicht. Trunk-Arbeit passt gut zu kontinuierlicher Auslieferung eines Produkts, kurze Feature-Branches passen aber auch zu planbaren Releases, wenn sie täglich synchronisiert werden.

Getrennte Linien sind dagegen gerechtfertigt, wenn Sie mehrere Versionen gleichzeitig unterstützen, auf App-Store-Freigaben warten oder regulatorisch getrennte Auslieferungen nachweisen müssen. Diese Anforderung betrifft die Release-Linie. Sie begründet keine wochenlangen Entwicklungszweige auf dem Hauptprodukt.

Ein Code-Freeze wirkt oft wie Sicherheit, ist aber meist ein verstecktes Integrationsfenster. Arbeit staut sich außerhalb, während der eingefrorene Stand getestet wird, und danach trifft alles auf einmal ein. Besser ist ein dauerhaft auslieferbarer Stand, bei dem einzelne Funktionen per Flag zurückhaltbar bleiben.

Für SMEs und Scale-ups folgt daraus eine unbequeme, aber nützliche Frage. Braucht das Team wirklich mehr parallele Arbeit, oder braucht es weniger halbfertige Arbeit in getrennten Zweigen? Prüfen Sie deshalb, ob Ihr eigentlicher Engpass das Release-Fenster ist oder die Review-Schlange davor.

Migrationsplan und Kennzahlen für den Erfolg

Das Ziel einer Umstellung ist eine mittlere Branch-Lebensdauer unter 24 Stunden. Das Etikett im Handbuch ist dabei Nebensache. Beginnen Sie mit einer Startphase von 30 Tagen: Eine Person besitzt in dieser Zeit die Kennzahlen Branch-Alter und Zahl aktiver Branches, und das Team hält höchstens drei Branches gleichzeitig offen. Keine neue Arbeit darf starten, wenn ihr Rückfluss in den Trunk absehbar länger als einen Tag dauern würde.

In sieben Schritten umstellen

1. Baseline vier Wochen messen: Erfassen Sie offene Branches, Branch-Alter, Lead Time, Fehlerrate nach Releases und Zeit bis zur Wiederherstellung.
2. Pipeline härten: Der Hauptzweig muss bei jedem Merge ein klares Grün oder Rot liefern, dem das Team vertraut.
3. Neue Arbeit begrenzen: Neue Branches fließen noch am selben Tag zurück, bestehende Langzeit-Branches werden in lieferbare Scheiben geschnitten.
4. Feature Flags gezielt einführen: Nur Funktionen, die vor dem fachlichen Abschluss in den Trunk müssen, bekommen ein Flag mit Eigentümer und Ablaufdatum.
5. Reviews verkleinern: Vereinbaren Sie kleine Diffs und eine Reaktionszeit in Stunden statt Tagen.
6. Code-Freezes abschaffen: Tun Sie das, sobald das Team die Wiederherstellung kleiner Änderungen sicher geübt hat.
7. Nach sechs bis acht Wochen vergleichen: Erklären Sie den Trunk erst dann zum Standard, wenn die Baseline den Fortschritt zeigt.

Die Reihenfolge ist bewusst gewählt. Wer Schritt drei vor Schritt zwei geht, merged häufiger in einen unzuverlässigen Stand. Wer Schritt vier ohne Ablaufdaten einführt, tauscht Branch-Wildwuchs gegen Flag-Wildwuchs.

Der DORA State of DevOps Report 2017 zeigt, dass leistungsstarke Teams Branches typischerweise nur wenige Stunden offenhalten, während leistungsschwache Teams Branches und Integrationen über mehrere Tage bestehen lassen. Die Branch-Lebensdauer wirkt dabei wie ein Fieberthermometer: Sie steigt, lange bevor ein Release scheitert. Messen Sie sie wöchentlich und nicht erst, wenn ein Merge schiefgegangen ist.

Kennzahlen als Abnahme verwenden

Lesen Sie die Tabelle paarweise. Steigt die Deployment-Frequenz, während die Change Failure Rate stabil bleibt oder sinkt, trägt die Umstellung. Steigt die Fehlerrate bei gleichzeitig grünem Trunk, ist das ein Abbruchsignal: Ziehen Sie zuerst Tests nach, statt die Integrationsfrequenz weiter zu erhöhen. Ein zweites Paar verdient denselben Blick. Bleibt die Wiederherstellungszeit hoch, obwohl die Branches jung sind, waren die gemergten Diffs größer, als die Kennzahlen vermuten lassen.

Der Engpass sitzt häufig in fehlender Senior-Kapazität für Pipeline-Arbeit, zügige Reviews und rückwärtskompatible Schnitte und weniger im Git-Modell selbst. Externe Unterstützung kann diese Kapazität optional ergänzen. Das nächste Arbeitsgespräch dreht sich am besten um Ihre gemessene Branch-Lebensdauer und die drei ältesten offenen Langzeit-Branches. Ein neues Tool ändert an beiden Zahlen nichts.

Einsatzfälle und Entscheidungsregeln

Vier wiederkehrende Lagen zeigen, wie die Entscheidung in der Praxis fällt. Jede Empfehlung gilt nur unter einer Bedingung, unter der sie kippen kann.

Vier Einsatzfälle einordnen

Erstens, das Scale-up mit mehreren Deploys pro Woche. Die Pipeline ist grün, der Produktpfad ist klar, unfertige Arbeit soll nicht auf das nächste Release warten. Hier passt Trunk-Based Development mit Feature Flags. Die Empfehlung kippt, sobald Flags ohne Ablaufdatum liegen bleiben und niemand weiß, welcher Pfad produktiv gilt.

Zweitens, das frühe Startup mit dünner Testabdeckung. Ein kleines Team ohne verlässliches Sicherheitsnetz arbeitet besser mit kurzen Feature-Branches und täglicher Synchronisation. Es verkürzt Schritt für Schritt die Branch-Laufzeit, bis der Trunk zuverlässig grün bleibt. Ein sofortiger Wechsel auf den Trunk würde Fehler nur schneller an alle verteilen.

Drittens, das regulierte oder versionspflichtige Produkt. Mehrere unterstützte Stände und nachprüfbare Freigaben erfordern getrennte Release-Linien für die Auslieferung. Der Entwicklungszweig sollte trotzdem täglich integrieren. Unternehmen, die ihre Zusammenarbeit ohnehin an wiederkehrenden agilen Prinzipien ausrichten, kennen diese Trennung, häufige Auslieferung bleibt Ziel, die Freigabeform folgt dem Kontext.

Viertens, das große Experiment. Ein neuer Checkout oder eine Datenmigration kann einen kurz gehaltenen Branch für die riskante Schnittstelle rechtfertigen. Der übrige Code fließt weiter in den Trunk. So bleibt das Experiment isoliert, ohne das gesamte Produkt anzuhalten.

Im DORA Accelerate State of DevOps Report 2021 waren Elite-Teams, die ihre Zuverlässigkeitsziele erreichten, 2,3-mal häufiger mit Trunk-Based Development verbunden, die Analyse zeigt jedoch keine isolierte Kausalwirkung der Branching-Strategie, weil der Vorteil zusammen mit kontinuierlicher Integration, automatisierten Tests, schnellen Reviews und entkoppelter Architektur entsteht. Lesen Sie den Befund als Bündel, nicht als Zaubertrick eines einzelnen Zweigs.

Die Entscheidung lautet nicht Branching ja oder nein, sondern ob Änderungen klein, täglich integrierbar und unabhängig schaltbar sind.

Drei Regeln für die Wahl

• Trunk-basiert arbeiten: Bei häufigen Deploys, grüner Pipeline und abschaltbaren Flags bleiben Branches unter einem Tag.
• Zuerst verkürzen: Fehlen Tests oder Review-Disziplin, synchronisieren Sie Feature-Branches täglich und messen vier Wochen, bevor der Trunk Standard wird.
• Nur die Linie trennen: Bei mehreren Versionen oder regulatorischer Freigabe trennen Sie diese Release-Linie, während die Produktarbeit täglich integriert bleibt.

Ein Pilotteam sollte nie an einem Monolithen ohne Tests starten. Wählen Sie stattdessen einen begrenzten Produktbereich, in dem Builds verläßlich laufen und Fehler schnell auffallen. Gelingt Trunk Based Development vs Feature Branch dort messbar, lässt sich die Praxis mit ruhiger Hand ausweiten.

Wenn Ihre Branch-Lebensdauer, Review-Schlange oder Pipeline die Umstellung heute ausbremst, hilft ein nüchterner Blick auf Kapazität und Arbeitszuschnitt mehr als eine Modelldebatte. Besuchen Sie PandaNerds, um mit erfahrenen Senior-Entwicklerinnen und Senior-Entwicklern zu sprechen, die sich in Ihr Team einfügen und Integrationsarbeit, Tests und Reviews im Alltag mit voranbringen. Bringen Sie dafür Ihre aktuellen Kennzahlen und offenen Langzeit-Branches mit, dann steht am Anfang keine Vertriebspräsentation, sondern eine konkrete Entscheidung über den nächsten Schritt.