Software-Entwicklung: Praxistaugliche Branching-Konzepte für Git

Die Versionsverwaltung Git erlaubt die Zusammenarbeit von mehreren Entwicklern am selben Projekt. Diverse Automationen erleichtern dabei die Arbeit.

Artikel verschenken
In Pocket speichern vorlesen Druckansicht 1 Kommentar lesen
Praxistaugliche Branching-Konzepte für Git

(Bild: Thorsten Hübner)

Lesezeit: 13 Min.
Von
  • Manuel Ottlik
Inhaltsverzeichnis

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.

Aber für welche Änderungen eröffnet man einen neuen Branch und wie organisiert man die Verzweigungen? Git selbst macht keine Vorgaben, wie man Branches nutzen soll. Man kann sie nach Belieben öffnen, schließen und benennen. Wenn man nicht rechtzeitig einen Plan entwickelt und mit allen beteiligten Entwicklern bespricht, hat man schnell Wildwuchs und wird früher oder später versehentlich den falschen Code ins fertige Produkt schieben.