So gut wie kein Programmierprojekt kommt um Git herum. Spätestens bei mehreren Projektteilnehmern sollte aber ein Workflow festgelegt werden, bei dem ihr euch folgende Fragen stellt: Wann wird ein neuer Branch erstellt? Wie wird er benannt? Wann soll gepusht werden? Für all diese Fragen gibt es verschiedene Ansätze. Einige wollen wir euch heute vorstellen.

Der einfache Workflow ist wohl der offensichtlichste. Ohne große Umstände werden Änderungen am Code nur auf dem Master-Branch gepusht. Mehr als diesen einen zentralen Branch gibt es nicht. Entwickler holen sich hier den aktuellen Commit, ändern den Code und pushen ihn für andere Developer zurück. Dieser „Workflow“ ist jedoch eher für kleine Ein-Mann-Projekte geeignet. Sobald das Projekt und das Team größer werden, verliert ihr sonst sehr schnell den Überblick und müsst euch mit viel mehr Merge-Konflikten herumschlagen als nötig.

Angenommen, das Projekt wird größer und ihr wollt eine bessere Struktur in eure Git-Verwaltung bringen, dann ist ein möglicher Schritt die Verwendung von Feature-Branches. Solch ein Feature sollte möglichst abgeschlossen und vom restlichen Projekt so unabhängig wie möglich sein. Ausgehend vom Master-Branch wird nun für jedes neue Feature ein eigener Branch erstellt. Ist das Feature abgeschlossen und lauffähig, wird der Branch mit dem Master-Branch gemerged.

Wie du in Git einen neuen Branch erstellst und alle weiteren wichtigen Befehle

Bei größeren Features kann es auch sinnvoll sein, die Branches hierarchisch aufzubauen: mit einer Art Unterfeatures. Solche Branches werden dann erst in den darüber liegenden Branch gemerged, bevor dieser mit dem Master-Branch zusammengeführt wird. Generell könnt ihr hier beliebig in die Tiefe gehen, solltet es aber der Übersicht wegen nicht übertreiben.

Statt für jedes Feature einen eigenen Branch zu erstellen, kann auch mit einem zweiten, langlebigen Developer-Branch gearbeitet werden. Auf dem wird solange programmiert, bis das Projekt für einen Release bereit ist. Dann wird der Developer-Branch in den Master gemerged. Auf dem Master-Branch befindet sich also nur Code, der jederzeit veröffentlicht werden kann.

Sobald mehrere Entwickler gleichzeitig an dem Projekt arbeiten wollen, treten jedoch ähnliche Probleme auf wie bei dem ganz einfachen Workflow. Für Ein-Mann-Projekte ist diese noch sehr einfache Strategie jedoch eine gute Lösung, da Release- von Entwicklungs-Code getrennt wird.

Wie du den Developer- mit dem Feature-Branch kombinierst, erfährst du auf der zweiten Seite.

Die Kombination der beiden zuletzt vorgestellten Workflows ist ziemlich einfach. Auch hier muss der Master-Branch jederzeit bereit sein, veröffentlicht zu werden. Auf ihm darf nur Code liegen, der fertige Features beinhaltet und auch getestet wurde. Feature-Branches kommen nicht mehr in Kontakt mit dem Master-Zweig, sondern lediglich mit dem Developer-Branch. Von hier aus werden neue Verzweigungen für Features erstellt, die am Ende zunächst in den Developer-Branch gemerged werden. Nun kann der Code auf dem Developer-Branch getestet werden. Erst wenn die Tests durchgelaufen sind und alle wichtigen Features für einen möglichen Release bereitstehen, darf der Code vom Developer-Branch auf den Hauptzweig gemerged werden.

Vor allem für große Projekte, die immer wieder neue Releases planen müssen, kann diese Erweiterung sehr sinnvoll sein. Sobald genug Features fertiggestellt sind, die veröffentlicht werden sollen, wird ausgehend vom Developer-Branch ein neuer Release-Branch erstellt. Darauf werden nun keine neuen Funktionen mehr ergänzt. Er dient lediglich dazu, Bugs zu beseitigen und den Code zu optimieren. Ist die Release-Version bereit für die Veröffentlichung, wird der Branch in den Master-, aber auch  zurück in den Developer-Branch gemerged. Diese Strategie ermöglicht das Optimieren des Releases fernab des Developer-Branches, wodurch ein anderer Teil des Teams parallel an neuen Features für die nächste Release-Version arbeiten kann.

Eine weitere kleinere Erweiterung dieser Strategie fügt einen weiteren Branch-Typ hinzu. Der Hotfix-Branch erlaubt unabhängig vom Developer-Branch, schnell benötigte Bugfixes direkt vom Master-Branch aus zu lösen. Dadurch muss ein schnell benötigter Release nicht den langen Umweg über den Developer-Branch gehen und kommt auch nicht in Kontakt mit bereits neu entwickelten Features.

Als Faustregel für die richtige Wahl solltest du dir folgendes merken: je komplexer dein Projekt, desto komplexer dein Workflow. Aber auch Ein-Mann-Projekte sollten entweder Developer-Branches oder Feature-Branches verwenden. Sobald mehr als ein Entwickler an einem Projekt arbeitet, sollte die Kombination beider Branch-Typen genutzt werden. Bei einem größeren Projekt sollte über den Einsatz des Release-Branches nachgedacht werden. Der einfache Workflow sollte nur bei kleinen „Nur zum Spaß“-Projekten genutzt werden, die nicht offiziell veröffentlicht werden sollen.

Egal für welchen Workflow du dich entscheidest – du solltest eine wichtige Konvention bei der Benennung der Branches einhalten. Beispielsweise in der Form eines Präfix: feature/my-branch oder release/version1.