Trunk-basierte Entwicklung

Überblick

Trunk-basierte Entwicklung ist ein Workflow, bei dem jeder Entwickler mindestens einmal täglich in einen gemeinsamen Branch — den Trunk (üblicherweise main) — integriert. Branches werden, wenn überhaupt, nur minimal genutzt und existieren für Stunden, nicht für Wochen. Es ist der Workflow hinter echter Continuous Integration und wird von Teams bevorzugt, die häufig deployen.

Die Kernidee

Je weiter sich dein Code von dem der anderen entfernt, desto schwieriger wird die Integration. Die Kosten eines Merges wachsen mit dem Ausmaß der Divergenz: Ein Branch, der zwei Wochen gelebt hat, häuft mehr Konflikte an, und diese Konflikte sind schwerer zu durchschauen, weil sich auf beiden Seiten so viel verändert hat.

Trunk-basierte Entwicklung bekämpft dieses Problem direkt, indem die Lücke klein gehalten wird. Du integrierst ständig in den Trunk — mindestens einmal täglich — sodass jeder Konflikt klein ist und erkannt wird, solange die Änderung noch frisch im Kopf ist. Es gibt keinen langlebigen develop-Branch und keine Big-Bang-Merges. Der Trunk ist jederzeit in einem auslieferbaren Zustand.

Es gibt zwei gängige Stile:

• Direkt in den Trunk committen. Kleine Teams committen direkt auf main und verlassen sich auf Pre-Push-Prüfungen und Pair-Review. Das ist die reinste Form.
• Kurzlebige Branches. Größere Teams erstellen für jede Änderung einen Branch, öffnen einen Pull Request und mergen innerhalb eines Tages oder zweier. Der Branch existiert nur so lange, wie CI benötigt und ein schnelles Review durchgeführt werden kann.

Ein typischer Kurzlebige-Branch-Zyklus sieht so aus:

git switch main          # start from the trunk
git pull                 # get everyone else's latest work
git switch -c quick-fix  # tiny, focused branch
# ...a few hours of work...
git switch main
git pull                 # pull again — others have merged since you branched
git merge quick-fix      # fast, because divergence is small
git push                 # back on the trunk within the same day

Das wiederholte git pull ist bewusst: Vor dem Merge zu pullen hält deinen Branch nah am Trunk, sodass der Merge trivial bleibt. Wenn du eine lineare History bevorzugst, führen manche Teams einen Rebase des kurzlebigen Branches auf main durch, anstatt zu mergen. Weitere Details zur Branch-und-Pull-Request-Mechanik findest du im Feature-Branch-Workflow.

Feature-Flags: unfertigen Code sicher ausliefern

Wenn alle täglich in den Trunk mergen, wie geht man mit einem Feature um, das zwei Wochen braucht? Einen Branch so lange am Leben zu halten, würde den ganzen Sinn zunichte machen. Die Antwort ist ein Feature-Flag — ein Laufzeitschalter, der entscheidet, ob neuer Code tatsächlich ausgeführt wird. Du mergst den unvollständigen Code, hältst ihn aber deaktiviert:

const featureFlags = { newCheckout: false };

function checkout() {
  if (featureFlags.newCheckout) {
    return "new checkout";
  }
  return "old checkout";
}

console.log(checkout()); // old checkout — flag is off in production

Der neue Code gelangt versteckt hinter dem Flag in die Produktion. Wenn er fertig ist, setzt du newCheckout auf true — kein erneutes Deployment erforderlich. So wird das Deployen von Code vom Veröffentlichen eines Features entkoppelt, was es ermöglicht, unfertigen Code sicher auf dem Trunk zu halten.

Ein paar praktische Regeln verhindern, dass Flags zum Chaos werden:

• Standardmäßig deaktiviert. Neuer Code ist verborgen, bis er bewusst eingeschaltet wird, oft zuerst für interne Nutzer.
• Flags als temporär betrachten. Sobald ein Feature vollständig gestartet ist, entferne das Flag und den toten else-Zweig — veraltete Flags häufen sich schnell an und machen den Code schwer lesbar.
• Beide Pfade testen. CI sollte den Code sowohl mit aktiviertem als auch deaktiviertem Flag ausführen, da beide in der Produktion eingesetzt werden.

Was es erfordert

Trunk-basierte Entwicklung ist schnell, aber nicht nachlässig — sie funktioniert nur mit starken unterstützenden Praktiken:

• Robuste CI: Jeder Push führt eine automatisierte Test-Suite aus, denn ein kaputtes Trunk blockiert das gesamte Team.
• Kleine, häufige Commits: Große Änderungen werden in sichere, inkrementelle Schritte aufgeteilt.
• Feature-Flags für alles, was nicht in einem einzigen kurzlebigen Branch abgeschlossen werden kann.
• Schnelles Code-Review, oft über kleine Pull Requests, die innerhalb von Stunden gemergt werden.

Wenn ein Review Tage dauert, leben Branches für Tage, und du betreibst keine trunk-basierte Entwicklung mehr. Die unterstützenden Praktiken sind keine optionalen Extras — sie sind das, was die Geschwindigkeit sicher macht.

Releases vom Trunk aus

Da der Trunk immer auslieferbar ist, sind Releases einfach. Zwei Muster dominieren:

• Release von der Spitze. Deploye main direkt, so oft du möchtest. Markiere jeden Release mit einem Tag, damit du genau identifizieren kannst, was ausgeliefert wurde:

  git switch main
  git pull
  git tag -a v1.4.0 -m "Release 1.4.0"
  git push origin v1.4.0

  Kopieren

• Einen Release-Branch erstellen. Für Produkte, die versionierte Releases ausliefern, erstelle einen kurzlebigen Release-Branch vom Trunk, stabilisiere ihn und tagge von dort aus. Fixes werden zuerst auf dem Trunk gemacht und dann per Cherry-Pick auf den Release-Branch übertragen — niemals umgekehrt, damit der Trunk die einzige Quelle der Wahrheit bleibt.

Beide Varianten halten den Trunk gesund: Er enthält immer den neuesten guten Code, und Releases sind Snapshots, die davon abgenommen werden.

Trunk-basiert vs. Gitflow

Gitflow optimiert für kontrollierte, versionierte Releases mit vielen Branch-Typen. Trunk-basierte Entwicklung optimiert für Geschwindigkeit und Continuous Delivery mit im Wesentlichen einem Branch. Wenn du mehrmals täglich deployest, passt trunk-basierte Entwicklung gut; wenn du versionierte Releases nach einem festen Zeitplan auslieferst, kann die Struktur von Gitflow besser für dich sein.

Wann man es einsetzen sollte

Greife zur trunk-basierten Entwicklung, wenn du häufig deployest, zuverlässige automatisierte Tests hast und Code-Reviews schnell halten kannst. Sie belohnt Teams, die kurze Feedback-Schleifen über schwere Prozesse stellen. Wenn deine Tests unzuverlässig sind, Reviews langsam sind oder du Arbeit in geplante Releases bündeln musst, sind der Feature-Branch-Workflow oder Gitflow weniger schmerzhaft. Einen Überblick über alle gängigen Modelle findest du in der Übersicht zu Git-Workflows.

Übung