Auf den grünen Zweig gekommen
Praxistaugliche Branching-Konzepte für Git
Die Versionsverwaltung Git erlaubt die Zusammenarbeit von mehreren Entwicklern am selben Projekt. Um Chaos zu vermeiden, braucht man Absprachen, wie man mit Branches umgeht. Diverse Automationen erleichtern dabei die Arbeit.
Viele kleine Git-Projekte funktionieren sehr lange ohne einen zweiten Branch. Gibt es nur einen Entwickler, weiß der am besten, an welcher Baustelle er gerade arbeitet und welche Dateien betroffen sind. Konflikte mit anderen Änderungen sind alleine unwahrscheinlich. Spätestens aber, wenn das Projekt wächst und zwei Entwickler gleichzeitig dieselbe Datei im master-Branch, dem Stammpfad von Git, bearbeitet haben, klemmt es beim Push zum Git-Server. Branches können aus der Bredouille helfen: Sie bilden eine Abzweigung vom Stamm und können zu einem späteren Zeitpunkt wieder zusammengeführt werden. In der Zwischenzeit sammelt der Branch Commits, was die Arbeit auf dem master-Branch nicht behindert. Ein neuer Branch ist also eine Kopie des aktuellen Stands, an der man in Ruhe arbeiten und experimentieren darf.
Ein Branch für eine neue Funktion kann durchaus monatelang offen bleiben. Andere Kollegen arbeiten derweil an ganz anderen Ecken des Codes. Mit solchen Feature-Branches wird man einer goldenen Regel bei der Arbeit mit Git gerecht: „Don’t push to master“. Die Idee dahinter: Im master liegt immer funktionsfähiger Code, der in diesem Zustand kompiliert, verpackt und zum Kunden oder auf den Server ausgeliefert werden darf. Experimente und Zwischenstufen haben im master-Branch nichts verloren.