Was ist Trunk Based Development? Die Praxis für Solo-Devs

Was ist Trunk Based Development? Es ist ein Branching-Modell, bei dem alle kleine Änderungen mindestens einmal am Tag in einen gemeinsamen Branch gemergt werden, meist main oder trunk genannt. Branches, falls man sie überhaupt nutzt, leben Stunden statt Wochen. Unfertige Arbeit wird hinter einem Feature-Flag versteckt, damit der Trunk bei jedem Commit auslieferbar bleibt. Das ist die ganze Idee, und sie ist weniger exotisch, als der Name klingt.

Hier ist die Szene, die das greifbar macht. Du öffnest ein Side-Projekt, an dem du seit drei Wochen nicht gearbeitet hast. Der Feature-Branch liegt 41 Commits hinter main, zwei Dateien haben Konflikte, und das, was du gebaut hast, passt nicht mehr zum umliegenden Code. Trunk Based Development ist die Gewohnheit, die verhindert, dass diese Szene überhaupt entsteht.

Was Trunk Based Development wirklich bedeutet

Die Referenzseite trunkbaseddevelopment.com beschreibt es als Quellcode-Modell, in dem Entwickler auf einem gemeinsamen Branch zusammenarbeiten und andere langlebige Entwicklungs-Branches vermeiden. Direkte Commits auf den Trunk sind für sehr kleine Teams in Ordnung. Pull Requests sind es ebenso, solange die Feature-Branches kurzlebig bleiben und aus der Arbeit eines einzelnen Arbeitsplatzes stammen.

Drei Regeln tragen den größten Teil des Gewichts.

• Mindestens einmal alle 24 Stunden in den Trunk mergen.

• Den Trunk grün halten: Ein kaputter Build auf main hat für alle oberste Priorität.

• Unfertige Arbeit mit Feature-Flags verbergen, statt sie auf einem Seitenbranch liegen zu lassen.

Auffällig ist, was fehlt. Es gibt keinen develop-Branch, keinen langen Release-Branch pro Feature und keine Integrationsphase am Ende, in der alle feststellen, dass ihr Code nicht zusammenpasst. Bei den älteren Modellen wird der Schmerz aufgeschoben und dann auf einmal bezahlt.

Warum das für die meisten kleinen Teams besser funktioniert

Langlebige Branches sind wie ein Kredit. Jeden Tag, den ein Branch lebt, driftet er ein Stück weiter von main weg, und die Zinsen zeigen sich als Merge-Konflikte, veraltete Annahmen und Reviews, die niemand abschließen kann, weil der Diff 60 Dateien berührt.

Die DORA-Seite zu Trunk-based Development verknüpft drei Praktiken mit besserer Liefergeschwindigkeit, Stabilität und Verfügbarkeit. Grundlage sind die State-of-DevOps-Daten von DORA aus den Jahren 2016 und 2017. Im Repository sollten höchstens drei aktive Branches existieren. Man mergt mindestens einmal täglich in den Trunk. Code-Freezes und Integrationsphasen entfallen. Das sind konkrete, messbare Ziele, und das ist in diesem Feld selten.

Für einen Solo-Dev oder ein Team aus drei Leuten ist das Argument noch einfacher. Kleine Merges lassen sich leicht reviewen, leicht zurücknehmen und sechs Monate später leicht verstehen, wenn du um 22 Uhr in git blame liest und dich fragst, was du dir damals gedacht hast.

Drei Gründe sprechen dafür, einer dagegen. Die Gründe: kleinere Diffs, schnelleres Feedback aus der CI und ein main, das du am Freitagnachmittag ausliefern kannst, ohne zu schwitzen. Der Grund dagegen: Wenn deine Tests dünn sind, verbreitet tägliches Mergen Fehler nur schneller. Dazu kommen wir weiter unten.

Direkt auf main committen oder kurzlebige Branches?

Beides zählt als Trunk Based Development. Der Unterschied liegt darin, wie viel Sicherheit du haben willst, bevor Code landet.

Direkt auf main zu committen funktioniert, wenn du allein oder zu zweit arbeitest, dein lokaler Build in unter einer Minute läuft und du deinen Tests vertraust. Das ist die schnellste Schleife, die es gibt. Die meisten Solo-Builder machen das bereits, ohne es so zu nennen.

Kurzlebige Branches mit Pull Request ergeben Sinn, sobald eine zweite oder dritte Person dazukommt oder wenn die CI auf einem sauberen Checkout laufen soll, bevor gemergt wird. Die Disziplin steckt im Wort kurzlebig. Ein Branch, der den nächsten Tag überlebt, driftet schon in das Modell zurück, das du eigentlich verlassen willst.

Eine praxistaugliche Routine sieht so aus:

• main pullen und einen Branch mit einem Namen anlegen, der sagt, was sich ändert.

• Die kleinste Änderung machen, die die Sache voranbringt, und den vollständigen lokalen Build laufen lassen.

• PR öffnen, CI laufen lassen, am selben Tag mergen.

• Den Branch löschen. Lass sie sich nicht stapeln.

Wenn eine Änderung nicht in einem Tag fertig wird, lautet die Antwort nicht ein längerer Branch. Die Antwort ist, die Änderung dünner zu schneiden.

Wie du unfertige Arbeit ausliefern kannst, ohne main zu brechen

Hier bleiben die meisten hängen. Wenn du täglich mergst, mergst du Code für Features, die es noch gar nicht gibt. Zwei Techniken lösen das.

Die erste ist das Feature-Flag. Der neue Codepfad ist gemergt, aber abgeschaltet, sodass Nutzer ihn nie sehen. Ein Flag kann so simpel sein wie ein Boolean in einer Umgebungsvariable:

const showNewCheckout = process.env.FEATURE_NEW_CHECKOUT === "true";

export function Checkout() {
  return showNewCheckout ? <NewCheckout /> : <OldCheckout />;
}

Für ein Side-Projekt reicht das. Wenn du Targeting, schrittweise Rollouts oder einen Kill-Switch ohne Redeploy brauchst, verdient sich ein verwalteter Dienst seinen Platz.

Die zweite Technik ist Branch by Abstraction, für größere Änderungen wie den Tausch eines Datenbank-Clients oder eines Zahlungsanbieters. Du setzt ein Interface vor die alte Implementierung, baust die neue dahinter, migrierst die Aufrufer Stück für Stück und löschst am Ende die alte. Jeder Schritt ist ein kleiner Merge in den Trunk, und nichts liegt auf einem langen Branch.

Eine ehrliche Einschränkung bei Flags: Sie sind Schulden. Ein Flag, das ein Jahr im Code bleibt, ist ein Branch in Verkleidung. Gib jedem Flag einen Verantwortlichen und ein Entfernungsdatum, und lösch es, sobald das Feature vollständig ausgerollt ist.

Was deine CI braucht, bevor du es ausprobierst

Trunk Based Development ohne Sicherheitsnetz ist nur schnell eintretende Kaputtheit. Bevor du dich auf ein tägliches Merge-Ritual festlegst, brauchst du drei Dinge.

• Einen Build, der bei jedem Push läuft und in Minuten fertig ist, nicht in einer halben Stunde.

• Tests, die anschlagen, wenn etwas Echtes kaputtgeht. Coverage-Zahlen zählen weniger als die Frage, ob eine schlechte Änderung gefangen wird.

• Einen schnellen Weg zum Rollback: den Commit zurücknehmen oder das Flag abschalten.

Statische Analyse ist eine günstige zusätzliche Schicht. Sie fängt eine Klasse von Problemen ab, etwa offensichtliche Bugs, Sicherheitsgerüche und duplizierten Code, bevor ein Mensch den Diff liest.

Wenn du der einzige Reviewer bist, hilft Tooling, das auf riskante Hotspots zeigt, noch mehr, denn niemand sonst wird dir sagen, dass die Datei, die du ständig anfasst, gerade zu einem Durcheinander wird.

Verlang am ersten Tag keine schwergewichtige Pipeline. Eine einzige Workflow-Datei, die main installiert, prüft, testet und ausliefert, ist ein völlig guter Anfang. Getestet, nicht optimal, und trotzdem die Mühe wert: Es ist die erste Version, die funktioniert, und du kannst sie später straffen.

Release-Branches, Hotfixes und was trotzdem Sorgfalt braucht

Trunk Based Development verbietet Release-Branches nicht. Manche Teams schneiden kurz vor einem Release einen Branch vom Trunk ab, härten ihn, liefern ihn aus und löschen ihn danach wieder. Andere releasen direkt vom Trunk und fixen nach vorn, wenn ein Bug auftaucht. Bei einer Web-App, die mehrmals pro Woche ausgerollt wird, ist Nach-vorn-Fixen fast immer einfacher.

Mobile Apps und alles mit einem langsamen Store-Review-Zyklus sind eine andere Geschichte. Dort kann es sinnvoll sein, pro Version einen kurzlebigen Release-Branch zu behalten, um Fehler in Versionen patchen zu können, die bereits bei Nutzern liegen. Auch dann gilt die Regel: Fixes landen zuerst auf dem Trunk und werden danach per Cherry-Pick übernommen, nie umgekehrt.

Hotfixes folgen derselben Logik. Auf dem Trunk fixen, ausliefern, fertig. Ein separater Hotfix-Branch, der nie zurückgemergt wird, ist der Weg, auf dem Teams am Ende zwei auseinanderlaufende Historien haben.

Eine realistische erste Woche

Am ersten Tag schaust du nach, wie dein Repository heute branched. Liste die offenen Branches und notiere das Alter jedes einzelnen. Alles, was älter als ein paar Tage ist, ist ein Kandidat zum Mergen oder Löschen. Allein das zeigt oft, wo die Reibung sitzt.

Am zweiten Tag baust du den Flag-Mechanismus ein. Selbst eine Umgebungsvariable reicht. Wähle ein laufendes Feature aus, setz seinen Einstiegspunkt hinter ein Flag und merge, was du hast.

Am dritten bis fünften Tag änderst du die Gewohnheit. Zerlege jede Aufgabe in Stücke, die an einem Tag landen können, und merge jedes Stück, sobald die CI grün ist. Erwarte, dass sich die ersten Stücke zu klein anfühlen. Sind sie nicht. Ein Commit, der eine ruhende Datenbankspalte oder eine ungenutzte Funktion hinzufügt, ist ein völlig gültiger Fortschritt, weil er sicher, reviewt und bereits integriert ist.

Am Ende der Woche weißt du zwei Dinge: ob deine Tests vertrauenswürdig genug sind und welche Teile deines Codes kleinen Änderungen widerstehen. Beides ist nützlich, und keines davon zeigt sich, wenn du an langen Branches arbeitest.

Du brauchst kein Dashboard, um das zu sehen. Schau dir an, wie lange deine Branches leben, wie oft main rot ist und wie lange eine Änderung vom ersten Commit bis zur Produktion braucht. Wenn das Branch-Alter sinkt und Deployments langweilig werden, zahlt sich die Gewohnheit aus.

Wenn du Zahlen zu den Auswirkungen auf Nutzer hinter Flags willst, kann ein Experimentier-Tool einen Rollout mit echten Metriken verknüpfen, statt sich auf das Bauchgefühl zu verlassen.

Für ein Team aus einer Person tut es auch ein einfaches Notizbuch. Schreib einen Monat lang jede Woche die Zeit von Merge bis Deployment auf. Der Trend sagt dir mehr als jede einzelne Zahl.

Lohnt sich der Wechsel, oder wartest du lieber?

Wechsel, wenn du allein, zu zweit oder in einem kleinen Team arbeitest, deinen Tests halbwegs traust und eine CI hast, die du verbessern kannst. Der Preis für den Versuch ist eine Woche leicht unbequemer kleiner Commits. Der Preis, auf langen Branches zu bleiben, wird in Konflikten und langsamen Reviews bezahlt und wächst mit jedem Mitarbeiter.

Warte, wenn du gar keine automatisierten Tests hast und keine Möglichkeit zum Rollback. Behebe das zuerst, denn tägliche Merges in einen ungetesteten Trunk verschieben den Schmerz nur.

Es ist keine perfekte Methode. Es ist eine brauchbare. Nimm die nächste kleine Änderung in deinem aktuellen Projekt, merge sie heute und schau, wie sich das anfühlt. Was ist das kleinste Stück deines aktuellen Features, das du heute Abend noch ausliefern könntest?