Branches in Git: Was dahintersteckt, wie sie funktionieren und warum sie so wichtig sind

Unser Gastautor erklärt die Hintergründe, zeigt Best Practices und typische Git-Workflows – so verpasst niemand im Team eine Abzweigung, und die Kollaboration gelingt.

Die meisten Software-Entwickler kommen früher oder später mit dem Versionskontrollsystem Git in Berührung, und spätestens im ersten großen Projekt mit mehr als einem Teammitglied steht Branching und Merging („Verzweigen und Zusammenführen“) auf der Tagesordnung. Doch was genau ist ein Branch in Git? Und was passiert bei einem Merge?

Nächster Abzweig: Teamwork

Stell dir vor, du arbeitest zusammen mit anderen Kolleginnen und Kollegen an einem Softwareprojekt; euer Team entwickelt und gestaltet einen Webshop. Vielleicht sitzt ihr in einem Büro zusammen und besprecht in den Kaffeepausen die anstehenden Aufgaben. Wahrscheinlicher ist jedoch, dass eure Arbeitsplätze an unterschiedlichen Orten sind, möglicherweise sogar in mehreren Ländern oder Zeitzonen.

Während eine Entwicklerin eine Idee für ein neues Feature hat und sofort mit dem Coden beginnen will, erhält ein Kollege einen Anruf vom Kunden: Ein Bug im Onlineshop muss schnell behoben werden. Gleichzeitig versucht ein Support-Mitarbeiter, die Dokumentation auf den neuesten Stand zu bringen.

In einem solchen Szenario ist es schwierig bis unmöglich, sich nicht gegenseitig in die Quere zu kommen. Jede Code-Änderung betrifft stets alle anderen. Eine Commit-Historie in Git mit einem einzigen Hauptzweig könnte so aussehen:

(Grafik: Tobias Günther)

Die gestrichelten roten Linien zeigen, wie unübersichtlich das Ganze ist. Welcher Commit gehört zu welchem Feature? Und auf welcher Code-Basis geht es künftig weiter?

Nix verpassen: Abonniere den t3n Newsletter! 💌

Bitte gib eine gültige E-Mail-Adresse ein.

Es gab leider ein Problem beim Absenden des Formulars. Bitte versuche es erneut.

Bitte gib eine gültige E-Mail-Adresse ein.

Hinweis zum Newsletter & Datenschutz

Den Wald vor lauter Ästen sehen

Bringen wir Struktur ins Projekt und ins Team: Git Branches. Ein Branch ist eine Abzweigung von der Haupt-Entwicklungslinie – eine solche Abzweigung solltest du immer dann nehmen, wenn du eine (stabile) Code-Basis verlassen möchtest, um etwa ein neues Feature oder einen Hotfix zu implementieren. Anstelle des recht chaotischen Workflows könnte ein Projekt mit Branches dann so aussehen:

(Grafik: Tobias Günther)

Jede kleine oder große Änderung entsteht in einem eigenen Branch, der die stabile Basis nicht beeinträchtigen kann – wie in einer Art Sandbox. Tritt ein Fehler in einem Branch auf, hat das keine Auswirkung auf die anderen Zweige und sie sind weiterhin sicher. Der Hotfix funktioniert? Das neue Feature wurde ausführlich getestet und für gut befunden? Dann ist es jederzeit möglich, einen Branch mit der Hauptlinie zusammenzuführen (Merge).

Die meisten Versionskontrollsysteme (VCS) unterstützen irgendeine Form von Branching; die Funktion ist also kein Alleinstellungsmerkmal von Git. Branching in Git ist allerdings so clever und leichtgewichtig, dass das Verzweigen und Wechseln zwischen den Entwicklungszweigen nahezu verzögerungsfrei abläuft und deutlich weniger Festplattenplatz als bei anderen VCS belegt.

Fassen wir zusammen:

1. Ein Branch ist eine komplett unabhängige Entwicklungslinie mit einer eigenen History.

2. Branches benötigen weniger Festplattenplatz als simple Kopien des Projektordners.

3. Das Merging ist normalerweise unkompliziert und verläuft meist ohne Benutzerinteraktion.

4. Mit Branches ist echtes Teamwork möglich; sie fördern die Kollaboration mehrerer Entwickler.

Baumpflege: Workflow mit Branches in Git

Branches in Git gehören zum Workflow dazu. In den meisten Projekten gibt es mehrere Zweige, an denen parallel gearbeitet wird, und auch das mehrmalige Zusammenführen klappt in der Regel problemlos. In vielen Teams hat man sich auf einen bestimmten Arbeitsablauf geeinigt und festgelegt, dass nur stabiler Code im Hauptzweig (meistens Master oder Main) liegt. Immer wenn ein Feature-Branch grünes Licht bekommt und als stabil gilt, wird er mit dem Master zusammengeführt. Es gibt also zwei verschiedene Arten von Branches:

1. Langlebige Branches (long-running): Sie bleiben während der gesamten Lebensdauer eines Projektes erhalten und sind nicht an bestimmte Features gebunden. Oft gibt es neben der Hauptlinie andere langlebige Branches wie etwa Staging oder Production, die bestimmte Stadien repräsentieren.

2. Kurzlebige Branches (short-lived), auch Topic- oder Themen-Branches genannt: Neue Funktionen oder Bugfixes landen in der Regel in kurzlebigen Branches. Die Zweige sind also nicht dafür gedacht, sie während der gesamten Lebensdauer eines Projektes zu pflegen. Stattdessen werden sie erstellt, um zu experimentieren, um neue Ideen zu implementieren oder Fehler zu beheben. Sobald ein kurzlebiger Branch in einen langfristigen Branch integriert wurde, kann er gelöscht werden.

Tipp: Es hat sich als Best Practice herausgestellt, niemals auf langfristige Branches zu committen. Code sollte nur gezielt in die Hauptlinie integriert werden. In vielen Projekten gibt es eine ausgewählte Gruppe von Entwicklerinnen und Entwicklern, die dazu die alleinige Befugnis haben.

In der Praxis: Verzweigen und Zusammenführen

Zum Erzeugen, Auflisten, Umbenennen und Löschen von Branches dient das gleichnamige Kommando „git branch“. Um einen neuen Abzweig zu erstellen, schreibst du den Branch-Namen hinter das Kommando. Ohne weitere Angaben listet der Befehl vorhandene Branches auf:

$ git branch new-design $ git branch Bugfix#213 new-design * master staging

Das Sternchen zeigt an, in welchem Branch du dich gerade befindest, also den aktuellen HEAD. Die HEAD-Datei ist ein Zeiger auf die aktuelle Verzweigungsreferenz. Um in den neuen Branch zu wechseln, verwendest du das Kommando „git checkout“ – eine praktische Abkürzung ist der Parameter „-b“. So erzeugst du einen neuen Branch und wechselst gleichzeitig in ihn hinein:

git checkout -b new-design

Achtung: Das Erstellen neuer Branches mit „git branch“ passiert immer im lokalen Repository. Ins Remote Repository auf dem Server wandern die neuen Abzweigungen erst, wenn du einen bestehenden lokalen Branch über „git push -u origin “ veröffentlichst.

Du hast dich beim Erstellen eines Branches vertippt? Das kommt vor, ist aber kein Problem. Das Kommando …

git branch -m

… benennt den aktuellen HEAD um. Möchtest du einen anderen Branch umtaufen, dann gibst du hinter „git branch -m“ den alten und den neuen Namen an.

Auch hier gilt wieder: Das ist nur im lokalen Repository möglich. Um einen Remote Branch umzubenennen, sind zwei Schritte nötig: alten Branch löschen und neuen Branch aus dem lokalen Repository pushen:

git push origin –delete git push -u origin

Zum Löschen eines Branches dient der Parameter „-d“; dahinter steht wieder der Name:

git branch -d

Es ist möglich, mehrere Branch-Namen anzugeben. Falls ein Abzweig Änderungen enthält, die noch nicht zusammengeführt wurden, funktioniert das Löschen allerdings nicht ohne Weiteres. In dem Fall hilft der Parameter „-f“, der den Vorgang erzwingt – Vorsicht, Datenverlust!

Zum Wechseln zwischen den Branches kannst du entweder „git checkout “ oder das vor rund zwei Jahren eingeführte Kommando „git switch“ verwenden.

Zum Schluss dieses Praxis-Teils wollen wir noch kurz über das Zusammenführen sprechen, das sogenannte Merging. Damit übernimmst du alle neuen Commits aus einem anderen Zweig in den aktuellen HEAD-Branch. Dazu sind lediglich zwei Kommandos erforderlich:

git switch staging git merge feature/new-layout

Der erste Befehl wechselt in den Branch, der die Änderungen des anderen aufnehmen soll, der zweite führt den Merge mit dem Branch aus, der die Modifikationen enthält.

Auf den grünen Zweig gekommen

Branches gehören zu Git dazu wie ein Stamm und Äste zu einem Baum. Wer das Konzept einmal verstanden hat, wird sich nicht nur in eigenen Projekten leichter tun, sondern vor allem das Teamwork stärken.

Tobias Günther

Tobias Günther ist einer der Gründer von Tower, einer beliebten Desktop-GUI für Git auf Mac und Windows. Daneben hat Tobias in zahllosen Blogposts, Workshops und Talks vielen Entwicklern dabei geholfen, Git besser zu verstehen und produktiver einzusetzen.

Das könnte dich auch interessieren

Read More