Web Development

Wozu Branches?

Ein Branch ist neuer Zweig für die Entwicklung.

Wenn ich eine neue Library ausprobieren will, aber noch nicht sicher bin, dass ich sie einsetzen werde, kann ich für das Experimentieren einen Branch einrichten.

Später möchten ich vielleicht den Branch wieder mit dem Haupt-Branch zusammenführen.

Branches anzeigen

Eine visuelle Darstellungen der Branches findet man z.B. in Gitlab unter Repository → Diagram. Jeder Knoten in diesem Graphen ist ein Commit.

Einen Branch erstellen

Um einen Branch anzuzeigen, zu erstellen oder zu löschen, verwenden wir den Befehl git branch. Der aktuelle Branch wird bei der Anzeige mit einem Sternchen markiert:

$ git branch
* main
  iss50

$ git branch experiment_mit_three_js

$ git branch
* main
  iss50
  experiment_mit_three_js

Aktuellen Branch wechseln

Das Erstellen und Löschen von Branches hat alleine noch keine Auswirkungen auf Dateien und ändert auch nicht in welchem Branch man sich befindet.

Ein Branch ist immer der aktuelle Branch. Man beginnt auf dem main Branch und kann mit git checkout zu einem anderen Branch wechseln:

zu einem anderen Branch wechseln
$ git checkout experiment_mit_three_js

# Abkürzung: Erstellen eines neuen Branches + checkout
git checkout -b foo

Wenn es sich um einen neu erstellten Branch handelt, ändern sich die Dateien in Ihrer Arbeitskopie nicht. Der neu erstellte Branch enthält dieselben Dateien wie der Branch von dem er gerade “abgezweigt” wurde.

Man kann nun in diesem Branch wie gewohnt arbeiten: git add, git commit, git add, git commit, …. Jetzt ist der Branch wirklich anders als Ursprungs-Branch. Wenn man jetzt einen anderen Branch auschecken ändern sich die Dateien im Dateisystem!

Deswegen ist es gut alle Änderungen im Branch zu committen bevor man in einen anderen Branch wechselt.

Hinter den Kulissen

Git behält den Überblick über alle Commits. Die Commits sind Nodes in einem Graphen. Jeder Commit hat eine Kante, die auf den vorhergehenden Commit verweist.

Ein Branch ist ein Zeiger auf einen bestimmten Commit. Wenn man noch keine weiteren branches erstellt hat gibt es nur einen main Branch, der auf den letzten Commit verweist, in dieser Abbildung ist das c2:

einen neuen Branch erstellen

Ein neuer Branch verweist nach dem Erstellen auf den gleichen Commit wie der aktuelle Branch. In dieser Abbildung wird der neue Branch mit dem Namen iss53 erstellt, der auch auf den Commit c2 verweist. (iss53 ist eine Abkürzung für Issue 53)

$ git branch iss53
$ git checkout iss53

Mit git checkout kann man zu einem anderen Branch wechseln. Das verändert die Branches nicht.

$ git branch
* main
  iss50

$ git checkout iss53

$ git branch
  main
* iss50

$ git checkout main

$ git branch
* main
  iss50

auf zwei verschiedenen Branches arbeiten

Wenn man am Projekt weiterarbeitet und auf beiden Branches neue Commits macht, kann man in eine Situation geraten wie in dieser Abbildung:

Nun ist der Inhalt der beiden Branches unterschiedlich. Wenn man mit git checkout in einen anderen Branch wechselt, kann man sehen wie sich die Dateien in der Working Copy ändern.

Merge = Zusammenführen

Der Prozess des Zusammenfügens von Branches wird mit dem englischen Wort “merge” bezeichnet. Git versucht, dies automatisch zu tun, und in vielen Fällen ist das auch kein Problem. Zum Beispiel, wenn in den beiden Branches unterschiedliche Dateien verändert wurden.

Man startet den Prozess auf dem Branch, der weiter bestehen soll, also meist auf main. Dort gibt man den Befehl git merge .... ein.

Wenn alles gut geht, wird die Ausgabe wie folgt aussehen:

$ git checkout main
$ git merge experiment_mit_three_js
Aktualisiere bdf7328..05d4ceb
Fast-forward
  README.md                |  189 +++++++
  index.html               |  218 ++++++++
 2 files changed, 407 insertions(+)

Nach der erfolgreichen Zusammenführung enthält der aktuelle Branch main alle Änderungen aus beiden Branches. Der andere Branch ist noch unverändert:

Wir brauchen den anderen Branch wahrscheinlich nicht mehr und können ihn mit -d löschen:

git branch -d iss53

Konflikte

Wie schon im Kapitel Git für Zwei beschreiben kann es zu Merge Konflikten kommen. Dann wird das Repository in einem “unmerged” Zustand belassen, und ich muss erst die Konflikte beheben und danach die betroffenen Dateien comitten.