Git: Mit Branches arbeiten (git branch)

Dieses Tutorial bietet eine kompakte Einführung zum Thema Git-Branches. Zunächst soll uns interessieren, wie Branches erstellt werden. Kommende Artikel widmen sich dann dem Auschecken von Branches und dem Mergen, um die Historie eines unabhängigen Branchs zu integrieren.

Zur Abgrenzung: Git-Branches sind nicht wie SVN-Branches. Letztere werden nur genutzt, um den zeitweiligen Entwicklungsfortschritt auf größerer Ebene einzufangen. Git-Branches dagegen bilden einen integralen Bestandteil der täglichen Arbeit in einem Git-Projekt.

git branch

Ein Branch repräsentiert eine unabhängige Entwicklungslinie. Er dient als Abstrahierung für den Edit/Stage/Commit-Prozess. Am besten können wir uns einen Branch als eine brandneue Kombination aus Arbeitsverzeichnis, Staging-Bereich und Projekthistorie vorstellen. Neue Commits werden in der Historie des aktuellen Branchs festgehalten, was in einem Fork in der Historie des Projekts resultiert.

Mit dem Befehl git branch können wir Branches erstellen, auflisten, umbenennen und löschen.

Nutzung

git branch

Listet alle Branches im Repository auf.

git branch <branch>

Erzeugt einen neuen Branch mit dem Namen <branch>. Dieser wird nicht ausgecheckt.

git branch -d <branch>

Löscht den spezifischen Branch. Die Operation ist sicher, da Git uns davor schützt, einen Branch zu löschen, der noch nicht gemergte Änderungen enthält.

git branch -D <branch>

Erzwingt das Löschen des Branchs, selbst wenn er nicht gemergte Änderungen enthält. Diesen Befehl können wir nutzen, wenn wir alle Commits, die zu einer bestimmten Entwicklungslinie gehören, dauerhaft entsorgen wollen.

git branch -m <branch>

Benennt den aktuellen Branch in <branch> um.

Hinweise

In Git bilden Branches einen integralen Bestandteil des täglichen Entwicklungsprozesses. Wenn wir ein neues Feature hinzufügen oder einen Bug fixen wollen – unabhängig von der Größe –, setzen wir einen neuen Branch auf, um unsere Änderungen abzukapseln. So wird sichergestellt, dass instabiler Code nicht direkt ins Hauptprojekt committet wird, und wir haben die Möglichkeit, die History unseres Features aufzuräumen, bevor wir es in den Haupt-Branch mergen.

Git Branches 1

Die Darstellung oben visualisiert beispielsweise zwei isolierte Entwicklungslinien, die eine für ein kleines Feature, die andere für eine längerfristige Funktion. Dadurch, dass wir sie in Branches entwickeln, ist es einerseits möglich, parallel an ihnen zu arbeiten, andererseits halten wir den master-Branch frei von fragwürdigem Code.

Tipps

Die Implementierung, die den Git-Branches zugrunde liegt, ist deutlich schlanker als im SVN-Modell. Statt Dateien von Verzeichnis zu Verzeichnis zu kopieren, speichert Git einen Branch als Referenz auf einen Commit. In diesem Sinne repräsentiert ein Branch die Spitze einer Reihe von Commits – er ist kein Container für Commits. Die Historie eines Branchs ist durch die Commit-Beziehungen extrapoliert.

Das hat maßgebliche Auswirkungen auf das Merging-Modell von Git. Während Merges in SVN auf Dateien basieren, können wir mit Git auf der abstrakteren Ebene der Commits arbeiten. Merges in der Projekthistorie können wir tatsächlich als Vereinigung zweier unabhängiger Commit-Historien ansehen.

Beispiel

Branch erstellen
Es ist wichtig zu verstehen, dass Branches nur Verweise auf Commits sind. Wenn wir einen Branch erstellen, muss Git lediglich einen neuen Verweis anlegen – das Repository wird nicht verändert. Wenn wir beginnen, haben wir ein Repository, das etwa so aussieht:

Git Branches 2

Dann erstellen wir einen Branch mit dem folgenden Befehl:

git branch crazy-experiment

Das Repo bleibt unverändert. Was wir erhalten, ist ein neuer Verweis auf den aktuellen Commit:

Git Branches 3

Auf diese Weise wird lediglich ein neuer Branch erstellt. Wenn wir beginnen wollen, ihm Commits hinzuzufügen, müssen wir ihn mit git checkout auswählen und dann die Standardbefehle git add und git commit verwenden. Mehr Infos bietet das demnächst folgende Tutorial zu git checkout.

Branch löschen
Wenn wir mit der Arbeit an einem Branch fertig sind und ihn in die Haupt-Codebasis gemergt haben, steht es uns frei, den Branch zu löschen, ohne dass uns etwas aus der Historie verlorengeht:

git branch -d crazy-experiment

Haben wir den Branch jedoch noch nicht gemergt, erhalten wir eine Fehlermeldung von Git:

error: The branch 'crazy-experiment' is not fully merged.
If you are sure you want to delete it, run 'git branch -D crazy-experiment'.

Dies schützt uns davor, unsere Referenzierungen auf diese Commits zu verlieren; wir würden quasi den Zugriff auf diese gesamte Entwicklungslinie einbüßen. Wenn wir diesen Branch wirklich löschen wollen (z.B. wenn es sich um ein gescheitertes Experiment handelt), können wir dies mit dem Parameter -D erzwingen:

git branch -D crazy-experiment

Damit wird der Branch entfernt, unabhängig von seinem Status und ohne Warnung. Mit entsprechender Vorsicht sollten wir dieses Kommando verwenden.

Das nächste Tutorial wird sich dann git checkout widmen.

Weiterführende Infos: Ihr Partner für Git und Stash

Kennen Sie Stash, Atlassians Git-Repository-Managementsystem? Stash bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben.

Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Stash. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.

99 Argumente für Stash als Git-Repository-Manager
Branch-basierte Git-Workflows mit Stash adaptieren
Echte Integration: Das Zusammenspiel von JIRA, Stash und Bamboo
Interview: Die Vorteile von Git in der Software-Entwicklung und die Möglichkeiten von Stash
So funktioniert die Lizenzierung von Atlassian-Produkten

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar