Was ist Trunk-Based Development? Guide für Entwickler
Zusammenfassung
Trunk-Based Development bedeutet: alle Entwickler mergen mindestens täglich in `main`. Keine langlebigen Feature-Branches -- Feature-Flags verbergen unfertige Arbeit vor Nutzern, der Code bleibt jederzeit produktionsreif. Die DORA-Forschung identifiziert TBD als starken Prädiktor für hohe Deployment-Frequenz. Das Modell scheitert ohne schnelle CI, funktionierende Feature-Flags und Stories, die an einem Tag abgeschlossen werden können.
Was ist Trunk-Based Development? Es ist eine Branching-Strategie, bei der alle Entwickler mindestens einmal täglich in einen einzigen gemeinsamen Branch -- üblicherweise main oder trunk -- committen. Keine langlebigen Feature-Branches. Der Code befindet sich jederzeit in einem produktionsreifen Zustand. Ist ein Feature noch nicht bereit, verbirgt ein Feature-Flag es vor den Nutzern -- kein Branch hält es vom Team fern.
Das ist die Kurzfassung. Was dahintersteckt: dein aktueller Workflow erzeugt wahrscheinlich mehr Risiken, als du ahnst.
Warum langlebige Branches zum Risiko werden
Die meisten Teams lernen Versionskontrolle über Feature-Branches: ein Branch pro Ticket, Merge nach Code-Review. Das klingt nach Ordnung.
Sobald ein Branch länger als 24 Stunden lebt, ist jeder Commit deiner Kollegen auf main ein zukünftiger Konflikt, den du noch nicht gesehen hast. In einem Team mit acht Engineers, die jeweils einen zwei Wochen langen Branch halten, verwaltest du keine einzelne Integration. Du verwaltest acht parallele Welten, die sich täglich weiter auseinanderbewegen. Merge-Day ist keine Aufgabe. Es ist eine Verhandlung.
Die DORA-Forschung -- die größte Längsschnittstudie zur Software-Delivery-Performance, durchgeführt über Tausende von Teams -- zieht hier eine klare Linie: Branches, die länger als 24 Stunden leben, sind ein prädiktives Signal für niedrigere Deployment-Frequenz und höhere Change-Failure-Rates. Elite-Teams integrieren mehrmals täglich. Der Rest mergt, wenn das Feature "fertig" ist -- was oft bedeutet: nie sauber.
Die versteckten Kosten sind nicht der Merge-Konflikt selbst. Es ist das Context-Switching, das nötig ist, um ihn drei Wochen nach dem Schreiben des Codes aufzulösen. Niemand erinnert sich mehr an die ursprüngliche Absicht.
Wie Trunk-Based Development in der Praxis funktioniert
Die Mechanik ist einfach. Du pullst main. Du machst eine kleine, kohärente Änderung. Du lässt die Test-Suite laufen. Du pushst auf main. Alles passiert, bevor du mittags Pause machst.
Für einen Einzelentwickler auf einem kleinen Repo läuft das ohnehin schon so. Für ein Team von zwanzig auf einem 300K-LOC-Monorepo ist es komplexer -- aber nicht unüberwindbar. Es braucht drei Praktiken, die zusammenwirken:
Kurzlebige Branches (optional, aber verbreitet): Manche Teams erlauben Branches bis zu zwei Tagen, bevor ein Merge erzwungen wird. Das bewahrt die Code-Review-Kultur, ohne wochenlange Divergenz zu erzeugen. Der Branch ist ein Review-Vehikel, kein Isolationsmechanismus.
Continuous Integration bei jedem Push: Jeder Commit auf main triggert einen vollständigen Build und die Test-Suite. Bricht etwas, bricht es in Minuten -- nicht nachdem ein zwei Wochen alter Feature-Branch am Freitag um 16 Uhr landet.
Feature-Flags für unfertige Arbeit: Unfertige Features gehen hinter einem Flag in die Produktion. Nutzer sehen nichts. Das Team integriert alles. Das ist der Teil, den die meisten Teams überspringen -- und der Hauptgrund, warum ihr erstes TBD-Experiment scheitert.
Keine dieser Praktiken ist exklusiv für Trunk-Based Development. Der Unterschied: TBD macht alle drei verpflichtend statt optional.
Feature-Flags: der Mechanismus, der TBD möglich macht
Ein Feature-Flag ist eine Bedingung in deinem Code, die zur Laufzeit ausgewertet wird. Wenn ein Flag deaktiviert ist, wird der neue Code-Pfad nicht ausgeführt. Wenn es aktiviert ist -- für einen bestimmten Nutzer, einen Prozentsatz des Traffics oder die gesamte Nutzerbasis -- schon.
Das klingt trivial. Die Konsequenz ist es nicht: Deployment wird von Release entkoppelt. Code gelangt kontinuierlich in die Produktion. Features starten, wenn sie bereit sind -- oder gar nicht, wenn der Rollout schiefläuft und du ihn in zehn Sekunden abschalten musst, statt drei Wochen Commits zurückzurollen.
Das Minimum-Setup braucht drei Dinge: eine Möglichkeit, Flags zu definieren, sie zur Laufzeit auszuwerten und sie ohne Redeployment zu ändern. Eine flache JSON-Config-Datei funktioniert für ein Drei-Personen-Team. Ein dedizierter Feature-Management-Service rechtfertigt seine Komplexität ab etwa zehn Engineers oder wenn Flags Targeting-Regeln brauchen wie "aktiviert für Nutzer in der Beta-Kohorte in Deutschland."
Ein wichtiger Punkt: Flag-Debt. Flags, die nach dem vollständigen Rollout nie bereinigt werden, werden zu bedingtem Spaghetti-Code. Ein Team, das TBD korrekt praktiziert, entfernt jeden Flag innerhalb eines Sprints nach dem vollständigen Feature-Rollout. Behandle Flags als temporäres Gerüst, nicht als permanente Konfiguration.
TBD vs. Gitflow: ein direkter Vergleich für 2026
Gitflow wurde 2010 für Software entwickelt, die in einem Quartalszyklus ausgeliefert wird. Es modelliert Releases als langlebige Branches. Für Teams, die täglich oder stündlich deployen, passt dieses Modell nicht mehr.
So sieht der Vergleich für ein Team mit CI/CD aus:
Branch-Lebensdauer: Gitflow läuft Tage bis Wochen. TBD läuft Stunden bis maximal 1-2 Tage.
Merge-Konflikte: Gitflow erzeugt häufige, schwerwiegende Konflikte. TBD erzeugt seltene, leichte -- weil Integrationslücken Stunden betragen, nicht Wochen.
Deploy-Frequenz: Gitflow koppelt Deployment an einen Release-Branch. TBD entkoppelt Deployment vollständig von Release.
Rollback-Mechanismus: Gitflow rollt zurück, indem ein Branch-Merge revertiert wird. TBD rollt zurück, indem ein Feature-Flag deaktiviert wird.
Onboarding-Komplexität: Gitflow erfordert das Verständnis von develop/main/hotfix-Konventionen. TBD hat einen Branch: main.
Erforderliche CI-Investition: Gitflow ist niedrig (Branches absorbieren das Risiko). TBD ist hoch (main muss jederzeit grün sein).
Gitflow ist nicht in jedem Kontext falsch. Wenn du eine Mobile-App in den App Store auslieferst und keine Hotfixes in Minuten pushen kannst, macht ein Release-Branch-Modell Sinn. Wenn du ein SaaS betreibst, bei dem du Deployments kontrollierst, ist die zusätzliche Branch-Struktur Overhead, der Koordinationskosten erzeugt, ohne Sicherheit hinzuzufügen.
Was die DORA-Metriken über Branching-Strategien sagen
Die DORA State of DevOps-Forschung verfolgt Software-Delivery-Performance seit 2014. Zwei Erkenntnisse aus den Daten sind hier direkt relevant.
Erstens: Trunk-Based Development ist eine der 24 Fähigkeiten, die im DORA-Modell Software-Delivery-Performance vorhersagen. Es gehört zum "Continuous Delivery"-Cluster -- DORA behandelt es als Infrastrukturpraxis, nicht als Teampräferenz.
Zweitens: Elite-Teams deployen mehrmals täglich. Niedrig-Performer deployen einmal pro Woche oder einmal im Monat. Langlebige Branches und seltene Integration erscheinen im langsameren Bereich dieser Verteilung, über mehrere Datenjahre hinweg.
Was die Forschung nicht behauptet: dass TBD Elite-Performance verursacht. Teams, die TBD erfolgreich einführen, haben in der Regel bereits automatisierte Tests, eine funktionierende CI-Pipeline und die Gewohnheit kleiner Commits. Trunk-Based Development deckt fehlende Grundlagen sofort auf. Ein Team ohne CI und mit 40% Test-Flakiness profitiert nicht vom Wechsel zu TBD. Sie werden main nur häufiger kaputt machen.
Praktisch bedeutet das: Bevor du TBD in Betracht ziehst, führe eine ehrliche Bestandsaufnahme durch. Wie lange dauert dein Build? Wie hoch ist die Flakiness-Rate eurer Tests? Wie viele Konflikte entstehen pro Woche bei eurem aktuellen Branching-Modell? Diese Zahlen zeigen, ob eure Grundlagen bereit sind -- oder ob Infrastrukturarbeit als erster Schritt kommen muss.
Wo Trunk-Based Development an seine Grenzen stößt
Drei Szenarien, in denen TBD mehr Probleme schafft als löst:
Stark regulierte Umgebungen mit obligatorischen Pre-Release-Freigabe-Gates: Wenn jedes Release ein Compliance-Sign-off benötigt, bevor es ausgeliefert werden kann, ist Continuous Deployment sowieso blockiert. Das Branching-Modell wird zweitrangig -- du stapelst Änderungen unabhängig von der Branching-Strategie.
Unterentwickelte Test-Suites: TBD erfordert eine schnelle, zuverlässige CI-Pipeline. Wenn Builds 45 Minuten dauern und 20% Flakiness haben, werden Entwickler Commits stapeln, um das Warten zu vermeiden. Das Problem ist die Test-Infrastruktur, nicht die Branching-Konvention.
Sehr große Teams mit inkonsistenter Code-Ownership: Bei Teams ab 50 Engineers, bei denen jedes Squad einen eigenen Service besitzt, funktioniert TBD gut auf Service-Ebene. Es auf ein gemeinsames Monorepo anzuwenden, bei dem alle alles anfassen, erfordert strenge Linting-Konventionen und CI-Ownership-Regeln, um main sauber zu halten.
In allen drei Fällen ist die Lösung keine andere Branching-Strategie. Die Lösung ist das zugrundeliegende Infrastrukturproblem. TBD macht das Problem nur schneller sichtbar.
Das ist tatsächlich einer der Hauptvorteile von TBD: Es fungiert als Frühwarnsystem. Teams, die sich seit Monaten mit schlechter CI-Qualität abgefunden haben, merken das erst, wenn sie täglich mergen müssen und jeden zweiten Tag main kaputt machen. Die Branching-Konvention ist nicht das Problem -- sie macht das eigentliche Problem sichtbar.
Migration ohne Lieferpause
Die Migration, die die meisten Teams falsch machen: TBD ankündigen, die Feature-Branch-Konvention abschaffen und zusehen, wie main in der ersten Woche kaputt geht.
Ein sichererer Weg:
Bestehende Branches behalten, eine Lebensdauer-Regel hinzufügen: Kein Branch lebt länger als 3 Tage. Das erzeugt den Druck häufiger Integration, ohne das Licht auszumachen.
CI zuerst instrumentieren: Bevor Mergen schnell geht, muss Mergen sicher sein. Stelle sicher, dass die Test-Suite grün ist, in unter 15 Minuten läuft und den Main-Branch bei Fehlern blockiert.
Ein Feature mit einem Flag gaten: Bau die Flag-Management-Fähigkeit auf, bevor du sie für jedes unfertige Feature brauchst.
Branch-Lebensdauer Woche für Woche verkürzen: Von 3 Tagen auf 2 Tage auf 1 Tag über sechs Wochen. Verfolge die Merge-Konflikt-Frequenz als vorlaufenden Indikator. Wenn sie sinkt, funktioniert das Modell.
Die alte Konvention erst aufgeben, wenn die neue funktioniert: Gitflow-Konventionen bleiben für alles außerhalb des Piloten bestehen. Beide Modelle 6-8 Wochen parallel zu betreiben ist in Ordnung.
Die eine Gewohnheit, die entscheidet, ob TBD sich durchsetzt
Trunk-Based Development scheitert nicht, weil Teams nicht auf main mergen können. Es scheitert, weil Entwickler nicht die Gewohnheit haben, Arbeit klein genug zu zuschneiden, um sie an einem Tag zu liefern.
Der zugrundeliegende Wandel ist nicht technischer Natur. Es geht darum, wie Arbeit in der Planung definiert wird. Eine Story, die sagt "implementiere den neuen Payment-Flow", ist ein zwei Wochen langer Branch, der darauf wartet, zu passieren. Eine Story, die sagt "füge den Route-Handler hinzu und gib einen 501 hinter Flag payment-v2 zurück", ist ein halbtägiger Commit.
Das erfordert PM-Beteiligung und Backlog-Hygiene, die die meisten Teams noch nicht aufgebaut haben. Die Branching-Strategie-Änderung dauert einen Tag zum Ankündigen. Die Scoping-Disziplin braucht sechs Monate zum Aufbauen.
Wenn dein Team bereits täglich funktionsfähige Software in die Produktion liefert, formalisiert TBD das, was du ohnehin tust. Wenn dein Team alle zwei Wochen mit einem Big-Bang-Merge am Ende liefert, wird TBD nicht komfortabel sein, bis sich die darunter liegenden Liefer-Gewohnheiten ändern.
Die Teams, die bei TBD bleiben, haben vor dem Wechsel in drei Dinge investiert: eine CI-Pipeline unter 15 Minuten, einen funktionierenden Feature-Flag-Service und Sprint-Zeremonien, die Stories produzieren, die klein genug sind, um sie an einem Tag abzuschließen. Ohne diese drei ist die Branching-Konvention der falsche Hebel.
Tools für TBD-Workflows
Trunk-Based Development auf Teamebene bedeutet mehr synchrone Abstimmung: kurze Standups, um Integrations-Drift zu erkennen, dokumentierte Konventionen für Flags und CI-Regeln, und Code-Reviews auf kritischen Pfaden.
Das Muster, das bei erfolgreichen TBD-Teams auffällt: Sie koordinieren kontinuierlich, nicht nur beim Review. Wenn du pushst, bevor jemand anderes denselben Bereich anfasst, brauchst du keine Konflikte aufzulösen. Das setzt voraus, dass du weißt, woran andere gerade arbeiten. Asynchrone Dokumentation, Standup-Notizen und kurze Retrospektiven helfen dabei, diesen Kontext zu verteilen, ohne ständige Meetings.