Branch und Checkout

Wir haben im vorherigen Kapitel Zweige, sogenannte Branches, bereits kennen gelernt. Wir konnten uns mit Hilfe von "git reset" durch die verschiedenen Versionen bewegen. Solche Zweige können nicht nur intern für die Versionierung von Git verwendet werden, sondern auch für die Dateien in Eurem Verzeichnis. Und es kommt noch besser: Für unser Verzeichnis sind Branches nicht einfach nur irgendwelche Zweige, sondern komplette Kopien des Produktivzweigs, dem sogenannten "master".

Aber jetzt mal alles nach ein ander

Gebt mal folgenden Befehl e

git branch

Ihr seht, das es bereits einen Branch mit dem Namen "master" gibt:

* master

Dieser Zweig (Branch) ist der Hauptzweig. In manchen Foren und Dokumentationen wird er auch als Produktivzweig bezeichnet. Alle Änderungen und Arbeiten, die wir in den letzten Kapiteln durch geführt haben, haben auf diesem Produktivzweig statt gefunden. Das Sternchen vor master besagt, dass es sich hierbei um den Standardzweig handelt.

Wofür brauche ich denn jetzt meinen eigenen Branch?

Wie Du in meinem bisherigen Tutorial gemerkt haben solltest, ist die Welt auch ohne Branches in Ordnung. Wenn Du alleine und nur für Dich an einem Buch oder an Deinem eigenen Projekt sitzt und Dich keiner stresst, dann wirst Du sehr wahrscheinlich keine Branches brauchen. Das ist auch der Grund warum im Internet überall steht, dass man Branches verwenden sollte aber nicht muss.

Aber wenn das Projekt bekannt ist, Kunden auf die Fertigstellung diesen Projektes warten und/oder andere Kollegen Dir rein reden, das hier und da noch Fehler auftauchen, dann sind Branches eine wahre Bereicherung. Aber in diesem Fall wird NIEMALS auf dem Produktivzweig (master) gearbeitet!!! Den Grund erkläre ich später. Stell zunächst sicher, dass Ihr eine saubere Arbeitsumgebung habt:

"git status" sollte Euch so was wie "working directory clean" mitteilen. Wenn das nicht der Fall ist, dann added und committet Eure Änderungen, bevor wir hier weiter machen.

Erstellen wir uns nun einen eigenen Branch:

git branch Kapitel_23

Wie Ihr den Branch benennt bleibt Euch überlassen.

Schaut Euch nun die vorhandenen Branches

git branch

Es gibt nun 2 Branches:

  Kapitel_2
* master

Da ich Euch gesagt habe, dass Ihr unter Verwendung von Branches NIEMALS auf master arbeiten sollt, wechseln wir nun mit checkout auf den neu angelegten Bran

git checkout Kapitel_23

Wenn Ihr "git branch" noch mal eingebt, dann seht Ihr, dass das Sternchen nun vor dem Branch Kapitel_23 steht.

Jetzt tun wir mal so als würden wir 4 Stunden lang arbeiten und schreiben 2-3 zusätzliche Zeilen Text unten in die hallo.txt. Ein anschließendes "git status" sollte Euch über die Veränderungen informieren und die Datei hallo.txt als "modified" anzeigen.

Es passiert, was kommen musste: Der Kunde ruft an und erklärt, dass er in Kapitel 2 einen Rechtschreibfehler gefunden hat, der, warum auch immer, sofort zu beheben ist. Gut das wir mit Branches arbeiten. Wir speichern unsere bisherige Arbeit ab und wechseln zu dem Produktivzweig

git checkout master

Von diesem Zweig aus erstellen wir uns nun einen neuen Branch und wechseln direkt in diesen Branch:

git checkout -b Fehler_Kapitel_2

Dieser Befehl ist eine Kombination aus beiden bisher gelernten Befehlen. Dieser erstellt den Branch und wechselt auch gleich in diesen neuen Branch hinein. Cool oder?

Bearbeitet nun in der hallo.txt irgendwo am Anfang ein Zeichen oder fügt etwas hinzu und speichert die Datei ab. Danach übertragt Ihr diese wieder in die Git-Versionierung:

git commit -a -m "Rechtschreibfehler behoben"

Der Parameter -a meldet automatisch alle bearbeiteten (modified) und gelöschten (deleted) Dateien für die Übertragung nach Git an. Wir konnten den Parameter vorher nicht verwenden, da der Parameter auf neu hinzugefügte Dateien keine Auswirkung hat.

Wechseln wir nun wieder zurück in den Produktivzweig:

git checkout master

Wenn Ihr Euch nun wieder die Datei hallo.txt anschaut, werdet Ihr feststellen, dass Eure Änderungen nicht vorhanden sind. Um nun die Änderungen, die Ihr in dem Branch "Fehler_Kapitel_2" in den Branch master einzubinden verwendet Ihr den merge-Befehl:

git merge Fehler_Kapitel_2

Schaut Euch jetzt noch mal die hallo.txt an. Wunderbar, die Änderungen wurden in den Produktivzweig eingebunden. Somit ist der master und der Fehler_Kapitel_2 Branch auf dem selben Stand. Zeit den überflüssigen Branch zu löschen:

git branch -d Fehler_Kapitel_2

Ein Branch kann nur dann gelöscht werden, wenn er nicht aktiv ist (Testen mit "git branch") und wenn alle Änderungen in den nächst höheren Branch übergeben (git merge) wurden.

Sollten wiedererwartend diese Änderungen nicht mehr von Interesse sein, dann macht es auch keinen Sinn mehr diese Änderungen zu mergen. In diesem besonderen Fall könnt Ihr den Branch folgendermaßen löschen:

git branch -D Fehler_Kapitel_2

Bleibt noch die Antwort auf die Frage, warum man unter Verwendung von Branches NIEMALS auf dem Produktivzweig (master) arbeiten soll. Ganz einfach: Macht mal die Änderungen direkt auf master. Nach 4 Stunden fleißigen Schreibens kommt nun der Kundenanruf und Ihr erstellt den neuen Branch zwecks Fehlerbehebung. Dieser neue Branch beinhaltet aber auch alle Texte, die Ihr in den letzten 4 Stunden geschrieben habt. Spätestens nach dem merge wäre zwar der bemängelte Fehler behoben, aber die unfertige Arbeit Eures Kapitels wäre auch in der Git-Versionierung gelandet. Bei Büchern und Kapiteln mag das alles noch nicht relevant sein, aber im Bereich der Programmierung könnte dieser unfertige Branch dazu führen, dass die Software/Programmierung zu Fehlern im System führt. Deshalb bitte immer einen eigenen Branch für jedes Kapitel/Feature oder anderweitige Programmabschnitte verwenden.