Auswahl einer Branching-Strategie

Trunk-based Development führt das Prinzip „Branches sollten kurzlebig sein" zu seiner logischen Konsequenz: Branches leben Stunden, nicht Tage. Entwickler pushen mehrmals täglich kleine, inkrementelle Änderungen auf main und nutzen Feature Flags, um unvollständige Arbeit vor Nutzern zu verbergen.

Die Vorteile sind real. Integrationsprobleme treten sofort auf, weil Branches nie weit von main abdriften. CI-Läufe sind schnell, weil der Diff klein ist. Es gibt keinen „Merge-Tag", weil das Mergen kontinuierlich erfolgt. Teams, die Trunk-based Development praktizieren, berichten von Deployment-Frequenzen, die 4–8× höher sind als bei Teams mit langlebigen Branches.

Die Anforderungen sind ebenfalls real. Trunk-based Development erfordert exzellente CI (Tests müssen schnell und zuverlässig sein), robuste Feature-Flag-Infrastruktur (man muss unvollständigen Code sicher ausliefern können) und hohes Vertrauen zwischen Entwicklern (kein Review-Gate bedeutet, dass der Autor die volle Verantwortung trägt). Für ein 4-Personen-Team mit starker CI und einer gemeinsamen Codebasis ist es oft die schnellste Arbeitsweise. Für ein 30-Personen-Team mit lückenhafter Testabdeckung ist es ein Rezept für einen kaputten main-Branch.

Dies ist GitHub Flow, einen Schritt weitergedacht — weniger Branches, kürzere Lebensdauer, mehr Abhängigkeit von Flags statt Isolation.

GitHub Flow ist der richtige Standard für die meisten Teams, und es lohnt sich zu verstehen, warum. Das gesamte Modell passt in drei Regeln: main ist immer deploybar, jede Änderung erfolgt auf einem kurzlebigen Branch, und Branches werden via geprüfter PRs in main gemergt. Das war's.

Es gibt keinen develop-Branch, keinen release-Branch, keinen hotfix-Branch. Ein Branch pro Änderung, ein PR pro Branch, ein Merge nach main. Wenn main einen neuen Merge erhält, kann man ihn deployen — manuell, automatisch oder nach Zeitplan. Die Einfachheit ist das Feature.

GitHub Flow funktioniert, weil es der Art entspricht, wie die meisten Produktteams tatsächlich ausliefern: kontinuierlich, in kleinen Schritten, ohne den Overhead der Koordination von Release-Trains. Ein Feature-Branch lebt ein oder zwei Tage, wird geprüft, gemergt und ausgeliefert. Wenn etwas kaputtgeht, macht man ein Revert und behebt es. Die Feedbackschleife ist eng.

Wo GitHub Flow Schwierigkeiten hat, ist, wenn man mehrere Produktionsversionen gleichzeitig pflegen muss (man liefert v2.3 aus, muss aber v2.1 für einen Kunden patchen) oder wenn der Deploy-Prozess langsam und teuer ist (sodass „einfach reverten" unrealistisch wird). Diese Szenarien brauchen ein strukturierteres Branching-Modell — aber sie sind die Ausnahme, nicht die Regel.

GitFlow wurde für eine Welt entworfen, in der Software auf CDs ausgeliefert wurde — versionierte Releases, lange QA-Zyklen, mehrere unterstützte Versionen im Feld. Wenn das Ihre Welt ist (Desktop-Apps, Embedded Systems, Unternehmenssoftware mit vertraglicher Versionsunterstützung), rechtfertigt die Struktur von GitFlow ihre Komplexität.

Das Modell fügt mehrere langlebige Branches hinzu: develop (Integration), release/* (Stabilisierung), hotfix/* (Notfall-Patches für Production) und main (Production-Zustand). Features branchen von develop ab, Releases forken von develop, wenn eine Version „feature-complete" ist, und Hotfixes branchen direkt von main.

Für Teams, die eine Webanwendung deployen — was die meisten Teams sind, die diesen Kurs lesen — ist GitFlow mit ziemlicher Sicherheit übertrieben. Der develop-Branch fügt eine Indirektionsebene zwischen Ihrer Arbeit und Production hinzu, ohne proportionalen Nutzen. Die Release-Branches ergeben nur Sinn, wenn Sie ein formales QA-Gate zwischen „Code complete" und „ausgeliefert" haben. Die Hotfix-Branches sind unnötig, wenn das Deployen eines Fixes Minuten statt Wochen dauert.

GitFlow ist nicht schlecht. Es ist für einen spezifischen Kontext entworfen. Wenn Sie diesen Kontext nicht haben (mehrere unterstützte Versionen, langsame Deploys, formale Release-Gates), zahlen Sie die Komplexitätssteuer ohne den Nutzen. Beginnen Sie mit GitHub Flow. Sie können später immer noch Struktur hinzufügen, wenn die Situation es erfordert — aber Sie werden es selten brauchen.