# Trunk Based Development was ist das: Alle Commits auf main URL: https://formula.dog/de/journal/trunk-based-development-was-ist-das Type: blog Locale: de Published: 2026-09-12 Updated: 2026-09-13 --- > Täglich auf main committen, kurzlebige Branches und Feature Flags: So funktioniert Trunk Based Development und wann es wirklich passt. Trunk Based Development was ist das? Alle Entwickler im Team pushen ihren Code mindestens einmal täglich auf einen einzigen gemeinsamen Branch -- den sogenannten Trunk, normalerweise `main`. Keine langlebigen Feature-Branches. Keine `hotfix-v2-backup-final`-Branches, die seit drei Wochen ungenutzt herumliegen. Kurze Branches leben nur Stunden, werden schnell gemergt und danach gelöscht. Der Code-Stand ist jederzeit deploybar. [Google setzt dieses Modell mit 35.000 Entwicklern um](https://trunkbaseddevelopment.com/). Hier ist, wie das funktioniert, wann es sinnvoll ist -- und wann nicht. ## Das "bericht_v2_ENDVERSION_bitte_dies_nehmen.xlsx"-Problem -- aber für Code Wer schon einmal einen gemeinsamen Ordner geöffnet und dort `bericht_v1.xlsx`, `bericht_v2_ENDVERSION.xlsx` und `bericht_BITTE_DIES_NEHMEN_greg_aenderungen.xlsx` nebeneinander vorgefunden hat, versteht das Problem, das Trunk Based Development lösen soll. Genau das passiert in Codebasen, wenn Teams mit langlebigen Feature-Branches arbeiten. Jemand startet in Woche eins eine neue Funktion. Der Rest des Teams liefert weiter. In Woche drei liegt der Branch Dutzende Commits hinter `main`. Das Mergen wird ein Wochenendprojekt, das niemand freiwillig übernehmen will. Konflikte häufen sich. Die Entwicklerin, die den Code geschrieben hat, hat vergessen, warum die Hälfte davon existiert. Das nennt man "Merge Hell". Gitflow -- die am weitesten verbreitete Alternative -- versucht dieses Problem mit formaler Struktur zu lösen: getrennte Branches für Features, Releases und Hotfixes, jeder mit einer definierten Lebensdauer. Die Struktur sieht auf dem Papier sauber aus. In der Praxis häufen sich Branches wie Tabellenversionen auf einem gemeinsamen Laufwerk, und der Integration Day wird zur Integration Week. Trunk Based Development dreht das um: Schluss mit dem Anhäufen von Integrations-Schulden. Heute auf `main` committen. ## Täglich auf main committen: Das ist das gesamte Modell Die Kernregel ist klar: Alle Entwicklerinnen und Entwickler pushen ihre Änderungen mindestens einmal alle 24 Stunden auf den gemeinsamen Trunk. Keine Ausnahme für "Ich bin noch nicht fertig" -- du commitest, was du hast, und du stellst sicher, dass der Build dadurch nicht kaputt geht. Das klingt beunruhigend, bis man die Mechanismen versteht, die es sicher machen: - **Kurzlebige Branches**: Du kannst weiterhin Branches nutzen, aber sie leben nur Stunden, keine Wochen. Ein Branch, der länger als zwei Tage existiert, ist ein Warnsignal, das untersucht werden sollte. - **Automatisierte Tests bei jedem Commit**: Deine CI-Pipeline führt die Test-Suite sofort aus. Wenn etwas kaputt geht, weißt du das in Minuten -- nicht erst am Ende des Sprints. - **Feature Flags**: Halbfertige Funktionen bleiben hinter einem Toggle versteckt, bis sie bereit zum Ausliefern sind. Nutzer sehen niemals unfertige Arbeit, auch wenn sie bereits im Produktionscode ist. Das Ergebnis ist eine Codebasis, die jederzeit auslieferbar ist -- nicht "auslieferbar, nachdem wir den Feature-Branch gemergt und eine Woche QA gemacht haben", sondern jetzt sofort, wenn nötig. Das ist das grundlegende Versprechen. ![Mehrere Code-Commits laufen auf einem gemeinsamen Haupt-Branch zusammen beim Trunk Based Development](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/f48347-inline1.webp) ## Kurzlebige Branches: In Stunden messen, nicht in Wochen Beim Trunk Based Development bist du nicht verbannt, Branches zu nutzen. Du bist verbannt, lange Branches zu nutzen. Ein Branch, den du um 9 Uhr morgens öffnest, den du am Vormittag bearbeitest, für den du nach dem Mittagessen ein Code-Review bekommst und den du vor 17 Uhr auf `main` mergest -- das ist genau die richtige Art. Deine Teammitglieder haben die Chance, die Arbeit zu reviewen, bevor sie im Trunk landet. Der Diff ist klein genug, um ihn in einem Durchgang zu verstehen. Konflikte, falls vorhanden, lösen sich in Minuten. Ein Branch, der drei Wochen läuft, während eine Entwicklerin in Isolation ein komplettes Authentifizierungssystem baut -- das ist das Problem. Wenn es dann ans Mergen geht, verbringt das Team mehr Zeit mit dem Auflösen von Konflikten, als es für das Bauen des Features gebraucht hat. Die praktische Schwelle, die die meisten Trunk-Based-Teams anwenden: Wenn ein Branch nach zwei Tagen noch nicht gemergt ist, muss sich etwas ändern. Entweder ist das Feature zu groß und muss in kleinere Stücke zerlegt werden, oder es braucht ein Feature Flag, damit partieller Code sicher auf `main` landet. Arbeit in kleinere Stücke zu zerlegen ist die Kerndisziplin, die Trunk Based Development tatsächlich schult. Statt "das gesamte Dashboard bauen" lieferst du "die Datenschicht hinzufügen", dann "das erste Diagramm hinzufügen", dann "die Filter verdrahten". Jedes Stück mergt auf `main`, wird getestet und wird unabhängig ausgeliefert. Das vollständige Feature entsteht schrittweise über mehrere Commits. Das klingt langsamer. In der Praxis ist es schneller, weil du Probleme findest, während der Kontext noch frisch und die Oberfläche noch klein ist. ## Feature Flags: Unfertige Arbeit deployen, ohne etwas zu brechen Feature Flags (auch Feature Toggles genannt) sind der Mechanismus, der Trunk Based Development praktikabel macht, wenn ein Feature nicht in einem einzigen kurzlebigen Branch fertiggestellt werden kann. Die Idee ist simpel: Verpacke neue Funktionalität in eine Bedingung, die nur aktiviert wird, wenn ein bestimmtes Flag eingeschaltet ist. `if (featureFlags.neuesDashboard) { renderNeuesDashboard(); } else { renderAltesDashboard(); }`Der neue Code wird in die Produktion deployt. Er läuft einfach nicht für Nutzer, bis du den Toggle umlegen. Das bedeutet konkret: - Entwickler können Work-in-Progress auf `main` committen, ohne jemanden zu beeinflussen - QA kann das Feature in der Produktion testen, indem das Flag für einen bestimmten Nutzer oder eine bestimmte Umgebung aktiviert wird - Ein Launch wird zu einer Konfigurationsänderung, kein Deployment-Ereignis - Wenn etwas bricht, schaltet man das Flag aus -- ohne Rollback oder Hotfix-Branch Feature-Flag-Infrastruktur skaliert von einer einfachen Umgebungsvariable, die beim Start geprüft wird, bis hin zu dedizierten Feature-Flag-Plattformen. Für ein Team, das gerade anfängt, reicht eine Konfigurationsdatei oder eine pro-Umgebungs-Variable aus. Der Punkt ist die Fähigkeit, nicht die Tooling-Komplexität. ![Feature-Flag-Toggle-Schalter steuern das Code-Deployment beim Trunk Based Development](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/d557e7-inline2.webp) ## Wann Trunk Based Development nicht die richtige Wahl ist Es lohnt sich, das direkt zu sagen: Trunk Based Development ist nicht universell besser. Es passt in bestimmte Kontexte. Lass es weg, wenn: **Deine CI/CD-Pipeline noch nicht bereit ist.** Trunk Based Development ohne automatisierte Tests bei jedem Commit ist keine Branching-Strategie -- es ist eine Codebasis, die schnell kaputt geht. Die Test-Infrastruktur muss vorhanden sein, bevor das Branching-Modell überhaupt funktionieren kann. **Das Team strukturbedingt nicht häufig committen kann.** Verteilte Teams, bei denen Mitarbeitende asynchron über Zeitzonen hinweg arbeiten, oder Open-Source-Projekte, bei denen Beitragende selten größere Batches einreichen, werden mit dem täglichen Commit-Rhythmus kämpfen. **Ihr in einer regulierten Umgebung mit obligatorischen Release-Fenstern arbeitet.** Einige Branchen verlangen externe Freigaben, lange QA-Zyklen und formelle Prüfpfade nach Release-Branch. Die strukturierten Release-Branches von Gitflow passen besser zu diesem Workflow. **Die Teamdisziplin noch nicht da ist.** Trunk Based Development erfordert, dass jeder Commit auf `main` entweder alle Tests besteht oder sofort behoben wird. Wenn dein Team gebrochene Builds toleriert, wird der gemeinsame Trunk zum gemeinsamen Problem aller. Gitflow ist eine vernünftige Wahl für Teams mit vierteljährlichen Release-Plänen, mehreren gleichzeitigen Features, die von separaten Squads entwickelt werden, oder Compliance-Anforderungen, die eine Branch-Level-Isolation erfordern. Die Frage ist ehrliche Passung -- nicht welcher Ansatz prinzipiell besser ist. ## Von Gitflow zu Trunk Based Development -- ohne Krise Wenn dein Team Gitflow verwendet und Trunk Based Development ausprobieren möchte, muss die Migration kein harter Schnitt sein. Beginne damit, keine neuen langlebigen Branches zu erstellen. Features, die nach der Entscheidung gestartet werden, bekommen kurzlebige Branches. Features, die bereits auf langen Branches in Bearbeitung sind, werden nach dem alten Modell abgeschlossen. Beide Ansätze koexistieren vorübergehend. Bevor du unfertigen Code auf `main` commitest, brauchst du Feature Flags. Das Einrichten eines grundlegenden Feature-Flag-Systems ist die Voraussetzung für alles andere. Ohne es bedeutet Trunk Based Development, unfertige Benutzeroberflächen in die Produktion zu liefern. Dann erzwinge CI auf dem Haupt-Branch: Automatisierte Tests laufen bei jedem Push, fehlgeschlagene Tests blockieren den Merge, und niemand mergt ohne einen erfolgreichen Build. Das ist der nicht verhandelbare Teil. Schließlich definiere die Zwei-Tage-Regel explizit: Jeder Branch, der älter als zwei Tage ist, löst ein Gespräch aus. Feature kleiner aufteilen, Flag hinzufügen oder schicken, was bereits fertig ist. Mach das in deinem Pull-Request-Prozess sichtbar. Die unbequeme Anpassung, mit der die meisten Teams konfrontiert sind: akzeptieren, dass "teilweise fertig" ein gültiger Commit-Zustand ist -- solange er hinter einem Flag versteckt ist und keine bestehenden Tests bricht. ## Was der DORA-Bericht über Deployment-Geschwindigkeit sagt Die DevOps Research and Assessment (DORA)-Berichte sind das Nächste, was die Softwareentwicklung an groß angelegter empirischer Forschung zu Teampraktiken hat. Der DORA-Bericht 2021 ergab, dass Elite-Teams 2,3-mal häufiger Trunk Based Development einsetzen als schwächere Teams. Elite-Performer im DORA-Framework deployen mehrmals täglich, mit Lead-Times vom Commit bis zur Produktion, die in Stunden statt Wochen gemessen werden. Trunk Based Development korreliert konsistent mit diesen Ergebnissen. Der wichtige Vorbehalt: Korrelation ist keine Kausalität. Hochleistungsteams übernehmen Trunk Based Development, weil sie bereits in die zugrunde liegende Disziplin investiert haben -- automatisierte Tests, solide CI/CD-Infrastruktur, Entwickler, die kleine, fokussierte Änderungen schreiben. Diese Grundlagen kommen zuerst. Trunk Based Development ist das Branching-Modell, das zu diesem Kontext passt -- nicht das, was ihn schafft. Biscuit hat das schnell raus: Ein guter Retriever versucht nicht, drei Bälle gleichzeitig zu tragen. Ein Commit, ein Review, ein Merge. Good boy. ![Visualisierung einer Continuous-Deployment-Pipeline mit Code-Fluss von Commits bis zur Produktion](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/6305c9-inline3.webp) ## Lohnt sich der Umstieg auf Trunk Based Development? Wenn dein Team pro Sprint nennenswert Zeit mit Merge-Konflikten verbringt, Releases verzögert, weil "der Feature-Branch noch nicht bereit ist", oder Branches hat, die so lange offen sind, dass niemand mehr weiß, wofür sie waren -- dann ist Trunk Based Development eine ernsthafte Evaluation wert. Der tägliche Commit-Rhythmus ist anspruchsvoll. Die Feature-Flag-Infrastruktur braucht Einrichtungszeit. Der kulturelle Wandel dauert einige Wochen. Aber das Ergebnis -- eine Codebasis, die jederzeit auslieferbar ist, Merge-Konflikte, die in Zeilen statt in Dateien gemessen werden, und Releases, die zur Routine statt zur Krise werden -- ist eine bedeutende Verbesserung der Art, wie das Team arbeitet. Klein anfangen: Ein Team, ein Sprint, CI läuft bei jedem Push, Feature Flags sind vorhanden. Schau, was sich in vier Wochen ändert. ## FAQ ### Was ist der Unterschied zwischen Trunk Based Development und Gitflow? Trunk Based Development bedeutet tägliche Commits auf einen einzigen Haupt-Branch ohne langlebige Feature-Branches. Gitflow dagegen nutzt separate langlebige Branches für Features, Releases und Hotfixes. TBD eignet sich für Teams mit starker CI/CD-Infrastruktur und häufigen Deployments; Gitflow passt besser zu vierteljährlichen Release-Zyklen und regulierten Umgebungen. ### Brauche ich CI/CD für Trunk Based Development? Ja, zwingend. Ohne automatisierte Tests bei jedem Commit auf main wird der gemeinsame Trunk schnell instabil. Die Grundlage ist eine CI-Pipeline, die sofort ausgeführt wird und fehlgeschlagene Builds blockiert. Trunk Based Development ohne CI ist keine Strategie -- es führt nur zu kaputtem Code auf dem gemeinsamen Branch. ### Was sind Feature Flags und wie helfen sie beim Trunk Based Development? Feature Flags sind Bedingungen im Code, die neue Funktionalität für Nutzer verstecken, bis sie bereit zum Ausliefern ist. Entwickler können so unfertige Arbeit auf main committen, ohne die Produktionserfahrung zu beeinflussen. Wenn das Feature fertig ist, wird der Flag umgelegt -- kein gesondertes Deployment nötig. ### Wie lang sollte ein Branch beim Trunk Based Development maximal sein? Die gängige Regel: höchstens zwei Tage. Branches, die kürzer als ein Arbeitstag leben, sind ideal. Jeder Branch, der nach zwei Tagen noch nicht gemergt ist, braucht eine Analyse: Entweder ist das Feature zu groß und muss zerlegt werden, oder es braucht ein Feature Flag, damit der teilfertige Code sicher landet. ### Was sagt der DORA-Bericht 2021 über Trunk Based Development? Der DORA-Bericht 2021 zeigt, dass Elite-Teams 2,3-mal häufiger Trunk Based Development einsetzen als schwächere Teams. Elite-Performer deployen mehrmals täglich mit Lead-Times in Stunden statt Wochen. Wichtig: Die Kausalität ist umgekehrt -- diese Teams haben bereits die nötige Infrastruktur aufgebaut und nutzen TBD als das Modell, das dazu passt. ### Passt Trunk Based Development zu verteilten Remote-Teams? Das hängt von der Commit-Frequenz ab. Synchron arbeitende Remote-Teams können täglich committen und TBD gut umsetzen. Asynchrone Teams über viele Zeitzonen hinweg oder Open-Source-Projekte mit unregelmäßigen Beitragsmengen haben mehr Schwierigkeiten mit dem täglichen Commit-Rhythmus. ### Wie führe ich Trunk Based Development ein, ohne das Team zu überfordern? Stoppt die Erstellung neuer langlebiger Branches. Features in Bearbeitung schließt ihr nach dem alten Modell ab. Richtet Feature Flags ein, bevor unfertiger Code auf main kommt. Erzwingt CI auf dem Haupt-Branch. Definiert die Zwei-Tage-Regel explizit. Der Übergang dauert einige Wochen, ist aber ohne harten Schnitt machbar.