Ein Git-Branching-Modell wählen

Ziel

Ein Branching-Modell wählen, das zu Release-Takt, Review-Praxis und Teamgrösse passt, und es schriftlich festhalten, damit Mitwirkende nicht raten müssen.

Voraussetzungen

Ein gemeinsames Repository, ein vereinbarter Integrations-Branch (häufig main), sowie ein Review- oder CI-Gate, das jede Änderung durchläuft, bevor sie diesen Branch erreicht.

Schritte

1. Festlegen, wie lange Änderungen ausserhalb des Integrations-Branchs leben dürfen. Kurzlebige Themen-Branches (Stunden bis wenige Tage) halten Merges klein; langlebige Branches sammeln Konflikte an.
2. Entscheiden, ob über main hinaus langlebige Branches nötig sind. Pro Git beschreibt eine Stabilitätsleiter (etwa main für Releases, develop für die Integration), die sich nur dann auszahlt, wenn Releases getrennt von der laufenden Arbeit unterstützt werden müssen.
3. Festlegen, wie eine Änderung in den Integrations-Branch gelangt: Fast-Forward-Merge, Merge-Commit, Squash oder Rebase. Eine Variante wählen und dokumentieren; gemischte Stile machen die Historie schwer lesbar.
4. Festlegen, wie Releases geschnitten werden: ein Tag auf main, oder ein Release-Branch, der nur Fixes erhält. Release-Branches sind gerechtfertigt, wenn eine Version über längere Zeit gepflegt werden muss.
5. Die Entscheidungen mit den genauen Befehlen in den Leitfaden für Mitwirkende schreiben, und alles durchsetzen, was sich per Tooling durchsetzen lässt (geschützte Branches, erforderliche Prüfungen).

Erwartetes Ergebnis

Jede mitwirkende Person kann drei Fragen beantworten, ohne nachzufragen: Von wo zweige ich ab, wie lange darf mein Branch leben, und wie kommt er zurück. Merges bleiben klein genug, um in einem Durchgang reviewt zu werden.

Grenzen und Prüfbasis

Das ist ein Entscheidungsverfahren, kein Benchmark. Teams, die laufend ausliefern, brauchen meist weniger Branches als das klassische Modell; Teams, die mehrere unterstützte Versionen pflegen, brauchen mehr. Die Wahl überdenken, wenn sich Release-Takt oder Teamgrösse ändern.