Die Nordlicht Reisen GmbH hat ihr Buchungsportal bisher so entwickelt: Jede Person arbeitet wochenlang auf einem eigenen Zweig, und kurz vor dem Termin werden die Zweige zusammengeführt. Das Zusammenführen dauert jedes Mal einen Tag und bricht regelmäßig etwas. Jetzt wächst das Team, und eine zweite Version des Portals für einen Partner muss parallel gepflegt werden. Sie sollen eine Verzweigungsstrategie entwerfen, die zu beidem passt.

Die Prüfung nennt diese Fähigkeit Design a branch strategy, mit den Stichworten Trunk-based, Feature Branch und Release Branch. Es geht nicht um Git-Befehle, sondern um eine Entscheidung mit Gründen.

Vorwissen: Was ein Commit, ein Zweig und ein Pull Request sind und wie Sie ein Repository bei GitHub und bei Azure Repos nutzen, kennen Sie aus K3, Lektion 3.7.1 und 3.7.2 (dort entstehen die Pipelines, die an Zweigen hängen). Wie Versionen aus Git-Tags entstehen, steht in K3, Lektion 3.7.4. Diese Lektion beginnt dort, wo es nicht um ein Repository, sondern um die Regeln eines Teams geht. Den Pull-Request-Ablauf mit Schutzregeln lehrt die nächste Lektion (2.2).

Was ein Zweig kostet

Ein Zweig in Git ist billig: Microsoft schreibt in der Anleitung zur Verzweigungsstrategie, Zweige seien „inexpensive to create and maintain“. Teuer ist etwas anderes, nämlich die Zeit, die ein Zweig vom Rest des Codes getrennt lebt. Microsofts Anleitung zur Wahl einer Strategie begründet, warum Zweige kurzlebig sein sollen: So bleiben Merge-Konflikte so selten wie möglich. Sie rät auch, nur dann zu verzweigen, wenn es nötig ist, weil Änderungen in DevOps kontinuierlich und häufig sind und Merge-Konflikte oft von Hand gelöst werden müssen. Statt zu verzweigen, soll man sich auf andere Mittel wie Feature Toggles stützen.

Daraus folgt der Rahmen für alles Weitere. Jede Strategie besteht aus drei Bausteinen, die Sie mischen:

Baustein Was es ist Was er kostet
Trunk (Hauptzweig, main) der eine Zweig, der immer baut und aktuell ist Disziplin: Er darf nie dauerhaft kaputt sein
Feature Branch (Themenzweig) kurzer Zweig für eine Änderung, geht per Pull Request in den Trunk Merge-Schuld, wenn er lange lebt
Release Branch (Freigabezweig) Zweig für eine ausgelieferte Version, wird nicht zurückgemergt jede aktive Version ist ein weiterer Stand, den Sie pflegen