Git-Flow ist ein Modell für Zweige mit festen Rollen für Entwicklung, Release und Korrektur. Vincent Driessen hat es 2010 beschrieben, und es hat die Arbeit mit Git in einem Jahrzehnt stärker geprägt als jede andere Anleitung.
- Git-Flow
Ein Modell für Zweige mit festen Rollen für Entwicklung, Release und Korrektur.
Beispiel: „Nach Git-Flow lag der fertige Stand auf main und die laufende Arbeit auf develop.“Auch GitFlow geschrieben. Es gibt dazu eine Erweiterung für die Kommandozeile, die die Zweige nach diesen Regeln anlegt und zusammenführt.
Abgrenzung zum Trunk-Based Development: Dieses arbeitet mit einem Hauptzweig und kurzen Abzweigungen. Git-Flow hält zwei dauerhafte Linien.
Welche Zweige Git-Flow vorsieht
Zwei dauerhafte und drei vorübergehende. Dauerhaft sind main mit dem ausgelieferten Stand und develop mit der laufenden Arbeit; vorübergehend je ein Zweig für eine Funktion, für die Vorbereitung eines Release und für eine eilige Korrektur.
Der Weg einer Änderung ist damit festgelegt: vom Funktionszweig nach develop, von dort in einen Release-Zweig, nach der Prüfung nach main und zurück nach develop.
Wofür Git-Flow zu schwer ist
Für Websites, die mehrmals pro Woche ausgeliefert werden. Dort kostet die doppelte Linie jeden Tag Zusammenführungen, die nichts beitragen, und die Frage, wo eine Änderung steckt, wird selbst zur Arbeit.
Driessen hat das 2020 in einem Hinweis über seinem Artikel selbst eingeräumt und für Anwendungen mit laufender Auslieferung ein einfacheres Modell empfohlen.
Was an Git-Flow trotzdem taugt
Die Rollen für Produkte mit Fassungen. Wer Software ausliefert, die Kunden installieren, pflegt mehrere Linien gleichzeitig, und dafür sind der Release-Zweig und der Korrekturzweig die passenden Werkzeuge.
Übernehmen lässt sich auch ein Teil davon. Ein Hauptzweig, kurze Funktionszweige und ein Korrekturzweig für den Notfall deckt in Webprojekten fast alles ab, siehe Hotfix.