Branch und Checkout

Wir haben im vorherigen Kapitel Zweige, sogenannte Branches, bereits kennengelernt. Wir konnten uns mithilfe 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 main.

Aber jetzt mal alles nacheinander

Gebt mal folgenden Befehl ein

git branch

Ihr seht, dass es bereits einen Branch mit dem Namen main gibt:

* main

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 stattgefunden. Das Sternchen vor main besagt, dass es sich hierbei um den Zweig handelt, auf dem wir gerade arbeiten.

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 dieses Projektes warten und/oder andere Kollegen dir einreden, dass hier und da noch Fehler auftauchen, dann sind Branches eine wahre Bereicherung. Aber in diesem Fall wird niemals auf dem Produktivzweig (main) 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 an:

git branch

Es gibt nun 2 Branches:

Kapitel_2
* main

Da ich Euch gesagt habe, dass ihr unter Verwendung von Branches niemals auf main arbeiten sollt, wechseln wir nun mit git checkout auf den neu angelegten Branch:

git checkout Kapitel_23

Wenn ihr git branch nochmal eingebt, dann seht ihr, dass das Sternchen nun vor dem Branch Kapitel_23 steht.

Jetzt tun wir 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 main

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-Versionsverwaltung:

git commit -a -m "Rechtschreibfehler behoben"

Der Parameter -a meldet automatisch alle bearbeiteten und gelöschten Dateien in der Git-Versionsverwaltung 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 main

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 main einzubinden verwendet ihr den merge-Befehl:

git merge Fehler_Kapitel_2

Schaut euch jetzt noch mal die Datei hallo.txt an. Wunderbar, die Änderungen wurden in den Produktivzweig eingebunden. Somit ist der main Branch und der Fehler_Kapitel_2 Branch auf demselben 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. Das erkennt ihr an dem Sternchen * nach Eingabe von git branch.

Sollten wieder erwartend 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 main arbeiten soll. Ganz einfach: Macht mal die Änderungen direkt auf main. 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-Versionsverwaltung enthalten. 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 Programmierung zu Fehlern im System führt. Deshalb bitte immer einen eigenen Branch für jedes Feature oder anderweitige Programmabschnitte verwenden.