Was ist Trunk-Based Development?

TLDR; Trunk-Based Development ist eine Branching-Strategie. Entwickler führen kleine Änderungen in einem gemeinsamen Branch zusammen, der meist main oder Trunk heißt. Sehr kleine Teams können direkt auf main arbeiten. Andere nutzen kurzlebige Branches und Pull Requests, die innerhalb von Stunden statt Wochen zusammengeführt werden. Das Ziel bleibt gleich: kleine Änderungen, frühes Feedback und ein jederzeit veröffentlichbarer Stand.

Was ist Trunk-Based Development?

Trunk-Based Development beschreibt, wie ein Team in einem Git-Repository zusammenarbeitet. Alle führen ihre Änderungen in einem zentralen Branch zusammen, dem Trunk. In vielen Git-Repositories heißt dieser Branch main.

Stell dir das Repository als Baum vor. Der Stamm ist die gemeinsame Entwicklungslinie. Ein Feature-Branch wächst davon weg. Je länger er sich unabhängig entwickelt, desto schwieriger kann es werden, ihn wieder mit dem Stamm zu verbinden. Trunk-Based Development hält diese Branches kurz.

Das bedeutet nicht, dass jeder direkt auf main arbeiten muss. Ein Team kann Pull Requests, Code-Reviews und kurzlebige Feature-Branches nutzen. Entscheidend ist, kleine Änderungen zu erstellen und sie mindestens einmal täglich zu integrieren.

Laut DORA (Englisch) gehört Trunk-Based Development zu den Voraussetzungen für Continuous Integration. Es reduziert getrennte Entwicklungslinien und die Komplexität beim Zusammenführen.

Wie funktioniert Trunk-Based Development?

Ein Entwickler beginnt mit dem aktuellen Stand von main, erstellt eine kleine Änderung, führt die Tests aus und integriert die Änderung, sobald sie sicher ist. Bei Pull Requests bleibt der Branch nur für das Review und die automatisierten Prüfungen bestehen. Nach dem Merge wird er gelöscht.

Hier ist ein kleines Beispiel mit dem Projekt aus unserem ultimativen Git Cheat Sheet:

# Mit dem aktuellen Stand von main beginnen
$ git switch main
$ git pull --ff-only

# Einen Branch für eine gezielte Änderung erstellen
$ git switch --create feature/add-branch-tip

# Die Änderung bearbeiten, prüfen und committen
$ code branches.md
$ git add branches.md
$ git commit -m "Add branch cleanup tip"

# Vor dem Teilen die Tests ausführen
$ npm test

# Den Branch für das Review veröffentlichen
$ git push --set-upstream origin feature/add-branch-tip

Wenn Prüfungen und Review erfolgreich sind, führst du den Pull Request zusammen und löschst den Branch. Beginne die nächste Änderung wieder mit dem aktuellen Stand von main.

Ein Pull Request sollte einen kleinen, verständlichen Schritt enthalten. Ergänze keine unabhängigen Aufgaben, während du auf das Review der ursprünglichen Änderung wartest.

Muss man direkt auf Main arbeiten?

Sehr kleine Teams können direkt auf main arbeiten, wenn sie schnelle automatisierte Tests und klare Regeln für einen fehlerhaften Build haben. Das ist die einfachste Form von Trunk-Based Development.

Viele Teams benötigen ein Review, bevor eine Änderung auf main gelangt. Sie nutzen einen kurzlebigen Branch, einen Pull Request und automatisierte Prüfungen. Auch das ist Trunk-Based Development. Ein Entwickler kann eine kleine Änderung allein oder gemeinsam mit einem anderen Entwickler umsetzen (Pair Programming). Der Branch wird innerhalb von Stunden, spätestens nach wenigen Tagen, wieder mit main zusammengeführt.

Ein Pull Request ist dabei kein Hindernis. Problematisch sind langlebige Branches. Wenn mehrere Entwickler wochenlang auf demselben Feature-Branch arbeiten, entsteht eine weitere Entwicklungslinie. Das Team erhält erst dann Rückmeldung zur Integration, wenn die Funktion fast fertig ist.

Warum nutzen Teams Trunk-Based Development?

Kleine, häufig integrierte Änderungen bieten mehrere Vorteile:

• Kleinere Merge-Konflikte: Ein Branch hat weniger Zeit, sich von main zu entfernen. Dadurch treffen weniger unabhängige Änderungen aufeinander.
• Früheres Feedback: Automatisierte Tests und Kollegen prüfen die Änderung, solange sie klein ist und der Entwickler die Details noch im Kopf hat.
• Überschaubare Änderungen: Eine kleine Änderung lässt sich leichter verstehen, testen, zurücknehmen und korrigieren als ein großes Paket.
• Einfachere Releases: Das Team hat eine aktuelle Entwicklungslinie und muss nicht entscheiden, welche langlebigen Branches zu einem Release gehören.
• Continuous Integration: Entwickler integrieren laufend, statt bis zum Abschluss einer ganzen Funktion zu warten.

DORAs Forschung verbindet kurze Branch-Laufzeiten und häufige Integration mit besseren Ergebnissen bei Softwarebereitstellung und Betrieb. Trunk-Based Development allein reicht dafür nicht aus. Es braucht zuverlässige Tests, schnelles Feedback und ein Team, das Fehler auf main zügig behebt.

Wie geht ihr mit Funktionen um, die länger als einen Tag dauern?

Die Entwicklung einer Funktion kann mehrere Wochen dauern. Ihr Branch sollte trotzdem kurzlebig bleiben. Teilt die Arbeit in kleinere Änderungen auf, die sich unabhängig und sicher integrieren lassen.

Noch unfertiges Verhalten für Nutzer könnt ihr hinter einem Feature Flag verbergen. Dieser Schalter hält die Funktion deaktiviert, obwohl der Code bereits auf main liegt. Später aktiviert ihr sie für euer Team, eine kleine Nutzergruppe oder alle Nutzer. Entfernt den Schalter nach der Einführung, damit vorübergehende Sonderfälle nicht dauerhaft zusätzliche Komplexität erzeugen.

Für größere interne Änderungen eignet sich Branch by Abstraction. Dabei ergänzt ihr eine stabile Schnittstelle um die bisherige Implementierung. Dahinter baut ihr den Ersatz in kleinen Schritten auf, stellt auf ihn um und entfernt anschließend die alte Implementierung. Der Leitfaden zu Trunk-Based Development (Englisch) erklärt diese Technik genauer.

Fragt euch: „Welchen kleinen, sicheren Schritt können wir heute integrieren?“ Die gesamte Funktion muss dafür noch nicht fertig sein.

Was braucht Trunk-Based Development?

Trunk-Based Development macht Integrationsprobleme früh sichtbar. Euer Team braucht die passenden Voraussetzungen, um sie schnell zu lösen:

• Automatisierte Tests, die innerhalb weniger Minuten hilfreiches Feedback liefern.
• Einen geschützten main-Branch mit verpflichtenden Prüfungen, wenn ihr Pull Requests nutzt.
• Kleine Änderungen, die Kollegen ohne lange Wartezeit prüfen können.
• Eine klare Regel, fehlerhafte Änderungen auf main zu korrigieren oder zurückzunehmen.
• Monitoring und automatisierte Deployments, wenn ihr häufig veröffentlicht.

Ohne diese Grundlagen kann häufige Integration zu häufigen Unterbrechungen führen. Verbessert zuerst die Tests und verkleinert die Änderungen.

Welche Fehler passieren häufig bei Trunk-Based Development?

• „Kurzlebige“ Branches wochenlang behalten: Wenn Branches regelmäßig für die gesamte Entwicklung einer Funktion offen bleiben, entspricht der Ablauf nicht mehr Trunk-Based Development.
• Die ganze Funktion in einen Pull Request packen: Trennt Umstrukturierungen, vorbereitenden Code und sichtbares Verhalten in Schritte, die sich unabhängig sicher integrieren lassen.
• Fehler auf Main ignorieren: Stoppt weitere Integrationen, korrigiert die verantwortliche Änderung oder nehmt sie zurück. Stellt den gemeinsamen Branch schnell wieder her.
• Feature Flags nicht entfernen: Legt für jeden vorübergehenden Schalter fest, wer verantwortlich ist und wann er entfernt wird.
• Integration und Deployment verwechseln: Ein Merge auf main bedeutet nicht, dass jede Änderung sofort veröffentlicht werden muss. Integration und Deployment können zu unterschiedlichen Zeitpunkten stattfinden.

Ist Trunk-Based Development bei KI-gestützter Entwicklung noch sinnvoll?

Ja. KI kann helfen, eine Änderung zu erstellen. Diese muss trotzdem mit dem restlichen System funktionieren. Wenn generierter Code als großes Paket ankommt, müssen Reviewer mehr verstehen, bevor sie beurteilen können, ob er bereit ist.

Trunk-Based Development gibt dieser Arbeit einen klaren Ablauf: eine kleine Änderung anfordern, prüfen, testen und integrieren. Erst dann beginnt der nächste Schritt. Häufige Integration zeigt auch, wenn getrennte Änderungen nicht zusammenpassen, unabhängig davon, ob Menschen oder KI-Agenten sie geschrieben haben.

DORAs Empfehlungen zu kleinen Arbeitspaketen (Englisch) raten ausdrücklich dazu, KI-gestützte Änderungen klein genug für sichere Reviews, Tests und Integration zu halten. Wir empfehlen, diese Arbeitsweise beizubehalten, auch wenn das Erzeugen von Code leichter wird. Schneller erzeugter Code hilft nur, wenn das Team ihn verstehen und überprüfen kann. Behaltet verpflichtende Reviews, automatisierte Prüfungen und Feature Flags für unfertiges Verhalten bei.

Was habt ihr gelernt?

Bei Trunk-Based Development steht ein gemeinsamer Branch im Mittelpunkt. Entwickler integrieren kleine Änderungen mindestens täglich, entweder direkt oder über kurzlebige Branches und Pull Requests. Automatisierte Tests, zügige Reviews, Feature Flags und ein funktionierender main-Branch sichern den Ablauf ab.

Wenn eure Branches wochenlang offen bleiben, beginnt kleiner. Wählt eine Änderung, die ihr heute prüfen, testen und integrieren könnt. Wiederholt diesen Ablauf morgen.

Im ultimativen Git Cheat Sheet findest du die Git-Befehle für Branches, Commits, Merges, Konflikte und die Zusammenarbeit mit Remote-Repositories.

Hat dir dieser Artikel gefallen? Teile ihn mit deinen Kolleginnen, Kollegen und Freunden.