Git
Chapters ▾ 2nd Edition

3.1 Git Branching - Branches auf einen Blick

Nahezu jedes VCS unterstützt eine Form von Branching. Branching bedeutet, dass Sie von der Hauptlinie der Entwicklung abzweigen und Ihre Arbeit fortsetzen, ohne an der Hauptlinie herumzubasteln. In vielen VCS-Tools ist das ein etwas aufwändiger Prozess, bei dem Sie oft eine neue Kopie Ihres Quellcode-Verzeichnisses erstellen müssen, was bei großen Projekten viel Zeit in Anspruch nehmen kann.

Manche Leute bezeichnen Gits Branching-Modell als dessen „Killer-Feature“, was Git zweifellos vom Rest der VCS-Community abhebt. Was ist das Besondere daran? Die Art und Weise, wie Git Branches anlegt, ist unglaublich leichtgewichtig, wodurch Branch-Operationen nahezu verzögerungsfrei ausgeführt werden und auch das Hin- und Herschalten zwischen einzelnen Entwicklungszweigen meistens genauso schnell abläuft. Im Gegensatz zu anderen VCS ermutigt Git zu einer Arbeitsweise mit häufigem Branching und Merging, sogar mehrmals am Tag. Wenn Sie diese Funktion verstehen und beherrschen, besitzen Sie ein mächtiges und einmaliges Werkzeug, welches Ihre Art zu entwickeln vollständig verändern kann.

Branches auf einen Blick

Um richtig zu verstehen, wie Git das Verzweigen realisiert, müssen wir einen Schritt zurücktreten und untersuchen, wie Git seine Daten speichert.

Wie Sie vielleicht aus Kapitel 1 Erste Schritte in Erinnerung haben, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern statt dessen als eine Reihe von Snapshots.

Wenn Sie einen Commit durchführen, speichert Git ein Commit-Objekt, das einen Zeiger auf den Snapshot des von Ihnen bereitgestellten Inhalts enthält. Dieses Objekt enthält auch den Namen und die E-Mail-Adresse des Autors, die Nachricht, die Sie eingegeben haben, und zeigt auf den Commit oder die Commits, die direkt vor diesem Commit stattfanden (zu seinem Vorgänger bzw. seinen Vorgängern): keine Vorgänger für den ersten Commit, einen Vorgänger für einen normalen Commit und mehrere Vorgänger für einen Commit, welcher aus dem Zusammenführen (engl. mergen) von zwei oder mehr Branches resultiert.

Um das zu veranschaulichen, lassen Sie uns annehmen, Sie haben ein Verzeichnis, welches drei Dateien enthält, und Sie fügen alle Dateien zur Staging-Area hinzu und führen einen Commit durch. Durch das Hinzufügen der Dateien zur Staging Area erzeugt Git für jede Datei eine Prüfsumme (den SHA-1-Hashwert, den wir in Kapitel 1 Erste Schritte erwähnt haben), speichert diese Version der Datei im Git-Repository (Git verweist auf diese als blobs) und fügt die Prüfsumme der Staging-Area hinzu:

$ git add README test.rb LICENSE
$ git commit -m 'The initial commit of my project'

Wenn Sie mit der Anweisung git commit einen Commit erzeugen, berechnet Git für jedes Unterverzeichnis (in diesem Fall nur das Wurzelverzeichnis des Projektes) eine Prüfsumme und speichert diese als tree-Objekt im Git-Repository. Git erzeugt dann ein commit-Objekt, welches die Metadaten und einen Zeiger zum tree-Objekt des Wurzelverzeichnisses enthält, sodass es bei Bedarf den Snapshot erneut erzeugen kann.

Ihr Git-Repository enthält jetzt fünf Objekte: drei blobs (die jeweils den Inhalt einer der drei Dateien repräsentieren), ein tree-Objekt, welches den Inhalt des Verzeichnisses auflistet und angibt, welcher Dateiname zu welchem Blob gehört, und ein commit-Objekt mit dem Zeiger, der auf die Root des Projektbaumes und die Metadaten des Commits verweist.

Ein Commit und sein Tree
Figure 9. Ein Commit und sein Tree

Wenn Sie einige Änderungen vornehmen und wieder einen Commit durchführen, speichert dieser einen Zeiger zu dem Commit, der unmittelbar davor gemacht wurde.

Commits und ihre Vorgänger
Figure 10. Commits und ihre Vorgänger

Ein Branch in Git ist einfach ein leichter, beweglicher Zeiger auf einen dieser Commits. Die Standardbezeichnung für einen Branch bei Git lautet master. Wenn Sie damit beginnen, Commits durchzuführen, erhalten Sie einen master-Branch, der auf den letzten Commit zeigt, den Sie gemacht haben. Jedes Mal, wenn Sie einen Commit durchführen, bewegt er sich automatisch vorwärts.

Note

Der „master“-Branch in Git ist kein spezieller Branch. Er ist genau wie jeder andere Branch. Der einzige Grund dafür, dass nahezu jedes Repository einen „master“-Branch hat, ist der Umstand, dass die Anweisung git init diesen standardmäßig erzeugt und die meisten Leute sich nicht darum kümmern, den Namen zu ändern.

Ein Branch und sein Commit-Verlauf
Figure 11. Ein Branch und sein Commit-Verlauf

Erzeugen eines neuen Branches

Was passiert, wenn Sie einen neuen Branch erzeugen? Nun, wenn Sie das tun, wird ein neuer Zeiger erstellt, mit dem Sie sich in der Entwicklung fortbewegen können. Nehmen wir an, Sie erzeugen einen neuen Branch mit dem Namen „testing“. Das machen Sie mit der Anweisung git branch:

$ git branch testing

Dieser Befehl erzeugt einen neuen Zeiger, der auf den selben Commit zeigt, auf dem Sie sich gegenwärtig befinden.

Zwei Branches
Figure 12. Zwei Branches, die auf die selbe Serie von Commits zeigen

Woher weiß Git, auf welchem Branch Sie gegenwärtig sind? Es besitzt einen speziellen Zeiger namens HEAD. Beachten Sie, dass dieser HEAD sich sehr stark unterscheidet von den HEAD-Konzepten anderer Versionsverwaltungen, mit denen Sie vielleicht vertraut sind, wie Subversion oder CVS. Bei Git handelt es sich bei HEAD um einen Zeiger auf den lokalen Branch, auf dem Sie sich gegenwärtig befinden. In diesem Fall sind Sie noch auf dem master-Branch. Die Anweisung git branch hat den neuen Branch nur erzeugt, aber nicht zu diesem gewechselt.

Auf einen Branch zeigender HEAD
Figure 13. Auf einen Branch zeigender HEAD

Sie können das leicht nachvollziehen, indem Sie den einfachen Befehl git log ausführen, mit dem Sie sehen, wohin die Zeiger der Branches zeigen. Diese Option wird --decorate genannt.

$ git log --oneline --decorate
f30ab (HEAD -> master, testing) add feature #32 - ability to add new formats to the central interface
34ac2 Fixed bug #1328 - stack overflow under certain conditions
98ca9 The initial commit of my project

Sie können die master- und testing-Branches sehen, die sich rechts neben dem Commit von f30ab befinden.

Wechseln der Branches

Um zu einem existierenden Branch zu wechseln, führen Sie die Anweisung git checkout aus. Lassen Sie uns zu dem neuen testing-Branch wechseln.

$ git checkout testing

Dadurch wird HEAD verschoben, um auf den Zweig testing zu zeigen.

HEAD zeigt auf den aktuellen Branch
Figure 14. HEAD zeigt auf den aktuellen Branch

Was bedeutet das? Nun, lassen Sie und einen weiteren Commit durchführen.

$ vim test.rb
$ git commit -a -m 'made a change'
Der Branch
Figure 15. Der Branch, auf den HEAD zeigt, bewegt sich vorwärts, wenn ein Commit gemacht wird

Das ist interessant, weil sich jetzt Ihr testing-Branch vorwärts bewegt hat, aber Ihr master-Branch noch auf den Commit zeigt, auf dem Sie sich befanden, als Sie die Anweisung git checkout ausführten, um die Branches zu wechseln. Lassen Sie uns zurückwechseln zum master-Branch.

$ git checkout master
HEAD bewegt sich
Figure 16. HEAD bewegt sich, wenn Sie auschecken

Diese Anweisung hat zwei Dinge bewirkt. Es bewegte den HEAD-Zeiger zurück, um auf den Branch master zu zeigen, und es setzte die Dateien in Ihrem Arbeitsverzeichnis zurück auf den Snapshot, auf den master zeigt. Das bedeutet auch, dass die Änderungen, die Sie von diesem Punkt aus vornehmen, von einer älteren Version des Projekts abzweigen werden. Sie macht im Grunde genommen die Änderungen rückgängig, die Sie auf Ihrem testing-Branch vorgenommen haben, sodass Sie in eine andere Richtung gehen können.

Note
Das Wechseln der Branches ändert Dateien in Ihrem Arbeitsverzeichnis

Es ist wichtig zu beachten, dass sich die Dateien in Ihrem Arbeitsverzeichnis verändern, wenn Sie in Git die Branches wechseln. Wenn Sie zu einem älteren Branch wechseln, wird Ihr Arbeitsverzeichnis zurückverwandelt, sodass es aussieht wie zu dem Zeitpunkt, als Sie Ihren letzten Commit auf diesem Branch durchgeführt haben. Wenn Git das nicht problemlos durchführen kann, lässt es Sie die Branches überhaupt nicht wechseln.

Lassen Sie uns ein paar Änderungen vornehmen und noch einen Commit durchführen:

$ vim test.rb
$ git commit -a -m 'made other changes'

Jetzt hat sich Ihr Projektverlauf verzweigt (siehe Verzweigter Verlauf). Sie haben einen Branch erstellt und sind zu ihm gewechselt, haben einige Arbeiten daran durchgeführt und sind dann wieder zu Ihrem Hauptzweig zurückgekehrt, um andere Arbeiten durchzuführen. Beide Änderungen sind in separaten Branches isoliert: Sie können zwischen den Branches hin und her wechseln und sie zusammenführen, wenn Sie bereit sind. Und das alles mit den einfachen Befehlen branch, checkout und commit.

Verzweigter Verlauf
Figure 17. Verzweigter Verlauf

Sie können sich dies auch mühelos ansehen, wenn Sie die Anweisung git log ausführen. Wenn Sie die Anweisung git log --oneline --decorate --graph --all ausführen, wird Ihnen der Verlauf Ihrer Commits so angezeigt, dass erkennbar ist, wo Ihre Branch-Zeiger sich befinden und wie Ihr Verlauf sich verzweigt hat.

$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project

Da ein Branch in Git in Wirklichkeit eine einfache Datei ist, welche die 40 Zeichen lange SHA-1-Prüfsumme des Commits enthält, zu dem sie zeigt, können Branches ohne großen Aufwand erzeugt und vernichtet werden. Einen neuen Branch anzulegen, geht so schnell und ist so einfach, wie 41 Bytes in eine Datei zu schreiben (40 Zeichen und einen Zeilenumbruch).

Das steht in krassem Gegensatz zu der Art und Weise, wie die meisten älteren Werkzeuge zur Versionsverwaltung Branches anlegen, weelches das Kopieren aller Projektdateien in ein zweites Verzeichnis einschließt. Das kann, in Abhängigkeit von der Projektgröße, mehrere Sekunden oder sogar Minuten dauern, während bei Git dieser Prozess augenlicklich erledigt ist. Da wir außerdem immer die Vorgänger mit aufzeichnen, wenn wir einen Commit durchführen, wird die Suche nach einer geeigneten Basis für das Zusammenführen (engl. merging) für uns automatisch durchgeführt, was in der Regel sehr einfach erledigt werden kann. Diese Funktionen tragen dazu bei, dass Entwickler ermutigt werden, häufig Branches zu erstellen und zu nutzen.

Lassen Sie uns herausfinden, warum Sie so handeln sollten.

Note
Einen neuen Branch erzeugen und gleichzeitig dorthin wechseln.

Es ist üblich, einen neuen Branch zu erstellen und gleichzeitig zu diesem neuen Branch zu wechseln – dies kann in einem Arbeitsschritt mit git checkout -b <newbranchname> passieren.