In diesem Artikel befassen wir uns mit dem Aufsetzen und der Handhabung von Branches (Zweigen). Wir gehen davon aus, dass du als Leser genug Erfahrung mit der Installation und Handhabung von einfachen Git-Features wie commit, push, und pull hast.

In der Welt der Versionskontrollsysteme ist Git mit Abstand eines der effektivsten und einfachsten Tools die uns zur Verfügung stehen, um unseren Arbeitsalltag bzw. unseren Workflow zu optimieren. In diesem Artikel zeigen wir euch, wir ihr Git mit git-flow effektiver nutzt.

Git Branching

Wir gehen in unserem Beispiel davon aus, dass zwei neue Features für unser aktuelles Projekt geplant sind. Diese wollen wir, ohne uns als Entwickler gegenseitig auf die Füße zu treten, zeitgleich erledigen.

Dafür gibt es in Versionskontrollsysteme sogenannte Branches. Bei Git enthält jeder Branch eine eigene Kopie des jeweiligen Repositories zum Zeitpunkt der Erstellung des Branches. Den Verlauf einer Feature-Entwicklung im normalen Git-Workflow erklärt der nächste Absatz. Person A erstellt hier zum Beispiel eine Navigation speziell für Smartphones in unserem Projekt.

Einfacher Workflow ohne Branching-Modell:

Als erstes beziehen (clonen) wir das Git-Respository vom Server, um eine lokale Kopie des gesamten Projektes zu erhalten. In diesem wird nun auf dem Hauptbranch (Master) das Feature „Smartphone Navigation“ nach und nach programmiert. Die Schritte schliessen jeweils mit commit und anschliessendem push der Änderungen an das globale Repository ab. Die Webseite auf dem Produktions-Server wird anschliessend mit einem pull aktualisiert.

Das Problem an diesem Beispiel ist Folgendes:
Sobald eine weitere Person am selben Projekt arbeitet kann es zu Überschneidungen kommen. Angenommen Person A arbeitet an der Smartphone Navigation während Person B einen wichtigen Bugfix einspielt. Dadurch, dass Person B seinen Bugfix so schnell wie möglich auf der Live-Instanz des Projektes haben will, wird nach dem Hinzufügen des Bugfixes sofort der Master-Branch auf den neusten Stand gebracht. Das hat die Nebenwirkung zur Folge, dass auch Teile des Codes von Person A auf den Live-Server geladen werden und somit Probleme bzw. Fehler produzieren werden, da man nicht sicher sein kann, dass Person A seine Arbeit beendet hat. Und seien wir ehrlich – in Projekten mit mehr als einem Entwickler kommt es IMMER zu solchen Zuständen.

Lösungsansatz mit Git und einem einfachen Branching-Modell

Um solche Probleme zu umgehen hat man in Git die Möglichkeit einen oder mehrere Branches zu erstellen. Ein Branch ist eine Abzweigung der Codebasis zu einem bestimmten Punkt. Ab diesem Punkt kann man auf seinem Zweig (Branch) parallel zum Beispiel zum Hauptstrang in Ruhe entwicklen und erst das fertige Feature wieder zurück mergen.

Hier ein Beispiel:
Person A möchte eine Navigation für Smartphones erstellen ohne jemandem in die Quere zu kommen und geht jetzt wie folgt vor:
Git-Repository vom Server ziehen für eine lokale Kopie des gesamten Projektes. Neuen Branch erstellen mit dem Namen „develop“.
Auf diesem Branch kann jetzt unabhängig von anderen Branches weiter gearbeitet werden. Jegliche Änderung auf dem neu erstellten Branch wird zunächst keinerlei Auswirkung auf andere Branches haben. Sobald das neue Feature fertig ist, wird Person A seine Änderungen pushen und seine Änderungen in den Hauptbranch „mergen“ (zusammenführen).
Dieses Merging vom Branch „develop“ in den Hauptbranch des Projektes bewirkt, dass alle Änderungen im Smartphone Branch nun auch auf dem Hauptzweig des gesamten Projektes verfügbar sind.

Sollte während der Entwicklungszeit der Smartphone-Navigation Person B einen kritischen Bugfix in den Hauptbranch pushen, kann der Administrator ohne Einfluss der Codeänderungen für die Smartphone-Navigation den Hauptbranch updaten. Der Bugfix der auf dem Hauptbranch von Person B eingefügt wird, hat keinerlei Auswirkungen auf die Arbeit von Person A (Smartphone-Navigation Branch). Auch werden Codeänderungen von Person A keinen Einfluss auf die Arbeit von Person B haben, da beide verschiedene Branches verwenden.

Wenn dann jedoch nach der Fertigstellung der Smartphone-Navigation das gesamte Projekt diese neue Navigation erhalten soll, wird der Branch des neuen Features, in unserem Fall „develop“, einfach mit dem Hauptbranch zusammengeführt, woraufhin alle anderen Projektmitglieder die neuen Änderungen schließlich auch erhalten. Ausgenommen davon sind natürlich wieder die Projektmitglieder, die sich gerade auf einem anderen Branch befinden.

Lösungsansatz git-flow als Branching-Modell

„Git-flow“ ist ein Tool das den Workflow von Git erweitert und fest spezifiziert. Es kann per Kommandozeile oder per Tool bedient werden. So bieten zum Beispiel Sourcetree von Atlassian und PhpStorm Untersützung für git-flow. Die sehr feste Spezifizierung von git-flow hält den Workflows konstant und fördert den dezentralisierten Entwicklungsansatz. Zusätzlich zu den bekannten Hauptzweigen „master“ und „develop“ werden sogenannte Support-Branches erstellt, welche später für differenzierte Aufgaben verwendet werden. Diese werden auf verschiedene Art und Weise mit unseren Hauptzweigen „master“ und „develop“ zusammengeführt. Wir werden diese Support-Branches anhand von drei Beispielen kurz erklären.

Support-Branches bei git-flow

Derzeit haben wir in unserem Projekt zwei Zweige, „master“ und „develop“. „Master“ ist die aktuelle Live-Version des Projektes während „develop“ einen aktuellen Entwicklungsstand darstellt. „Git-flow“ fügt nun drei weitere Arten von Branches zu unserem Workflow: „release“, „feature“, und „hotfix“.

Hotfix-Branches

Der Hotfix-Branch wird von den beteiligten Entwicklern lediglich dazu benutzt Fehlerbehebungen des Live-Systems durchzuführen. Sobald ein Fehler behoben ist, wird der Hotfix-Branch geschlossen und mit „master“ und „develop“ zusammengeführt. Dieses führt auf der einen Seite zu einem sauber aktualisierten Live-System und auf der anderen Seite wird der Hotfix in die Entwicklungsschiene transferiert, da sämtliche anderen Branches vom „develop“ Branch abhängen.
Hotfix-Branch Workflow © nvie.com

Feature-Branches

Der Feature-Branch wird als Zweig zur Erstellung neuer Funktionen verwendet. Sobald eine neue Funktionalität abgeschlossen ist, wird der Feature-Branch auf mit dem Develop-Branch zusammengeführt und kann auf einer Testinstanz unabhängig von unserem Master branch getestet werden. Feature-Branches sollten in dieser Struktur lediglich lokal vorkommen.
Feature-Branch Workflow © nvie.com

Release-Branches

Der Release-Branch wird bei jedem neuen Release oder großen Codeänderung (Milestone) benutzt. Ein Release kann zum Beispiel eine Sammlung von verschiedenen Features sein, welche als Release-Branch gruppiert bzw. zusammengefasst werden, um gemeinsam deployed zu werden. Ein Release-Branch sollte immer mit „master“ als auch „develop“ zusammengeführt werden, wobei letzterer für die Qualitätssicherung inklusive Testing Vorrang hat.

Fazit

Das Arbeiten mit git-flow oder generell die korrekte Nutzung von Branching stellt eine qualitätssichernde sowie Workflow-optimierende Maßnahme da, die uns hilft sauber und getrennt voneinander unseren Aufgaben nach zu gehen, ohne die Arbeit des Anderen zu beeinträchtigen.