Hauptbereich
Agency
entwickler-tools

Git-Branching-Strategien — Trunk-Based, Git-Flow und GitHub-Flow im Vergleich

Redaktion ·

Eine Branching-Strategie ist die Vereinbarung darüber, wie dein Team mit Branches arbeitet: Wer arbeitet wo, wie lange leben Zweige, wann und wie wird zusammengeführt. Es gibt nicht die eine richtige Strategie — es gibt die, die zu Teamgröße, Release-Rhythmus und Automatisierungsgrad passt. Dieser Artikel stellt die drei verbreiteten Modelle vor, erklärt den Pull-Request-Workflow und gibt eine pragmatische Empfehlung für kleine Teams.

Trunk-Based Development

Beim Trunk-Based Development arbeiten alle nah am Hauptzweig (dem „Trunk”, meist main). Branches sind extrem kurzlebig — Stunden bis maximal ein, zwei Tage —, und Änderungen werden sehr häufig integriert.

Der Vorteil: Weil ständig in den Trunk gemergt wird, gibt es kaum divergierende Zweige und kaum große Merge-Konflikte. Fehler zeigen sich sofort, nicht erst Wochen später. Das passt perfekt zu Continuous Integration und schnellen Releases.

Der Preis: Trunk-Based funktioniert nur mit starker Automatisierung. Ohne verlässliche CI, automatisierte Tests und Schutzmechanismen wird das ständige Integrieren in den Hauptzweig chaotisch und riskant. Wer ohne Test-Sicherheitsnetz direkt auf main arbeitet, bricht reihenweise Builds.

Git-Flow

Git-Flow ist das mächtigste und zugleich schwerste Modell. Es arbeitet mit mehreren langlebigen Branches:

  • main — der produktive, immer auslieferbare Stand
  • develop — der Integrationszweig für die nächste Version
  • feature/* — Branches für einzelne Features
  • release/* — Branches zur Stabilisierung einer Version vor dem Launch
  • hotfix/* — für dringende Korrekturen direkt auf main

Das gibt viel Kontrolle und unterstützt parallele Feature-Arbeit sowie mehrere gepflegte Versionen gleichzeitig. Genau diese Macht ist aber die Schwäche: Lang lebende Branches sammeln Merge-Konflikte an — je länger ein Zweig lebt, desto schwerer die Zusammenführung. Reviewer sehen riesige Pull Requests statt kleiner Häppchen, und Fehler tauchen spät auf. In einer CI/CD-Welt ist Git-Flow für die meisten Teams Overhead.

GitHub-Flow

GitHub-Flow ist der pragmatische Mittelweg und das verbreitetste Modell. Es kennt nur zwei Sorten Branches:

  • main — immer auslieferbar
  • kurzlebige feature-Branches — pro Aufgabe ein Zweig, der per Pull Request wieder in main gemergt wird

Der Ablauf: Branch von main abzweigen, Änderung machen, Pull Request öffnen, Review und CI durchlaufen lassen, mergen, Branch löschen. Einfach, schnell, verständlich — und mit dem Pull Request als Sicherheitsnetz gegenüber dem direkten Arbeiten auf main. GitHub-Flow liegt zwischen Trunk-Based (Geschwindigkeit, hohe Automatisierungsanforderung) und Git-Flow (Kontrolle, hoher Overhead).

Der Pull-Request-Workflow

Ob GitHub-Flow oder Trunk-Based — das Herzstück moderner Zusammenarbeit ist der Pull Request (auf GitHub) bzw. Merge Request (auf GitLab). Der Ablauf:

  1. Branch und Änderung. Ein kurzlebiger Branch enthält eine abgegrenzte Änderung.
  2. Pull Request öffnen. Der Branch wird zum Merge in main vorgeschlagen.
  3. Review. Mindestens ein Teammitglied liest die Änderung und kommentiert. Kleine PRs sind hier Gold wert — sie lassen sich gründlich prüfen, riesige nicht.
  4. CI-Checks. Automatisierte Tests, Linter und Builds laufen gegen den PR. Schlägt etwas fehl, wird nicht gemergt.
  5. Merge. Erst wenn Review und CI grün sind, wandert die Änderung in main.

Dieser Ablauf hält den Hauptzweig stabil und macht Änderungen nachvollziehbar.

Kurzlebig vs. langlebig

Die wichtigste Erkenntnis steckt in der Branch-Lebensdauer. Kurzlebige Feature-Branches (Stunden bis Tage) sind fast immer besser: weniger Konfliktpotenzial, schnellere Integration, kleinere und besser reviewbare PRs. Langlebige Branches (Wochen) sind die Hauptquelle für Merge-Schmerz und späte Fehlerentdeckung. Git-Flows release- und hotfix-Zweige haben ihre Berechtigung, wenn du mehrere Versionen pflegen musst — für die meisten Web-Projekte mit kontinuierlichem Deployment sind sie unnötiger Ballast.

Empfehlung für kleine Teams

Für kleine, schnelle Teams (zwei bis fünf Entwickler) lautet die Empfehlung fast immer: GitHub-Flow oder Trunk-Based mit Pull Requests und solider CI. Git-Flow lohnt sich nur, wenn du echte Mehr-Versions-Anforderungen hast (etwa eine Software, die in mehreren parallelen Releases gepflegt wird).

Konkret: Starte mit GitHub-Flow. Es ist einfach, der PR gibt dir ein Review- und CI-Sicherheitsnetz, und es skaliert von zwei auf fünfzig Entwickler. Wenn deine Automatisierung reif ist und ihr noch mehr Tempo wollt, ist Trunk-Based der nächste Schritt.

Ergänzend lohnt sich eine Commit-Konvention. Conventional Commits — ein einfaches Format wie feat:, fix:, docs: vor der Commit-Nachricht — hält die Historie lesbar und lässt sich für automatische Changelogs und Versionierung auswerten. Saubere Branches plus saubere Commits ergeben eine Historie, mit der man Monate später noch arbeiten kann.

FAQ

Welche Branching-Strategie ist die beste? Es gibt keine universell beste. Für kleine Teams mit kontinuierlichem Deployment ist GitHub-Flow meist ideal: einfach, mit PR-Sicherheitsnetz, breit erprobt. Trunk-Based ist schneller, verlangt aber starke Automatisierung. Git-Flow passt nur bei echten Mehr-Versions-Anforderungen.

Was ist der Unterschied zwischen GitHub-Flow und Trunk-Based? Beide setzen auf kurzlebige Branches und main als auslieferbaren Stand. GitHub-Flow schaltet immer einen Pull Request mit Review und CI dazwischen. Trunk-Based treibt das Prinzip weiter: noch kürzere Branches, teils direktes Arbeiten am Trunk, und verlässt sich dafür auf starke automatisierte Tests.

Warum sind kurzlebige Branches besser? Je länger ein Branch lebt, desto stärker driftet er von main weg — Merge-Konflikte häufen sich, und Reviewer bekommen riesige, schwer prüfbare PRs. Kurzlebige Branches integrieren häufig, halten Konflikte klein und decken Fehler früh auf.

Wann lohnt sich Git-Flow trotzdem? Wenn du mehrere Versionen parallel pflegen musst — etwa eine On-Premise-Software, bei der Version 2.x und 3.x gleichzeitig Sicherheitsupdates brauchen. Die release- und hotfix-Branches sind dann ein echtes Werkzeug, kein Overhead.

Wie hängen Branching-Strategie und CI zusammen? Eng. Jede Strategie mit häufiger Integration (Trunk-Based, GitHub-Flow) lebt von automatisierten Tests und Builds, die jeden Pull Request prüfen, bevor er in main landet. Ohne CI fehlt das Sicherheitsnetz, und häufiges Mergen wird riskant statt befreiend.

Themenuebersicht

Entwickler-ToolsVersionskontrolle