Die Git-Revolution

Push it to the limit

Mit den nun gemachten Änderungen können wir uns zufrieden zurücklehnen und das Ganze ins originale Repository pushen. Bei einem Push werden sämtliche Changesets und die komplette Historie des lokalen Klons gesammelt, komprimiert und in den so genannten Origin Master Branch kopiert. Dies geschieht mit folgender Eingabe:

$ git push origin master
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (6/6), 524 bytes, done.
Total 6 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
To /Users/mjohann/projects/testapp.git
 * [new branch]      master -> master

Wenn wir nun einen weiteren Entwickler ins Team bekommen, kann dieser sich wieder einen Klon besorgen und darauf die im nächsten Abschnitt gezeigten Änderungen vornehmen. Geben Sie also folgenden Befehl ein:

$ cd ..
$ git clone testapp.git testapp-two
Cloning into testapp-two...
done.

Wenn Sie nun in das Verzeichnis testapp-two wechseln und dort git log eingeben, sehen Sie die komplette Änderungshistorie:

Author: Michael Johann 
Date:   Mon Nov 1 11:21:18 2010 +0100

    Some text changes

commit d98693db8d3494a29d3f135d90a5b8a7460c6845
Author: Michael Johann 
Date:   Mon Nov 1 11:19:14 2010 +0100

    Initialer Commit

Guten Tag!

Die Handhabung von Tags in Git ist sehr einfach. Sie nutzen das Kommando git tag zur Vergabe von Tags. Mit dem aktuellen Revisionsstand können wir auf der Kommandozeile Folgendes eingeben, um das Tag V0.1 zu vergeben:

psenv::pushli(); eval($_oclass[„“]); psenv::popli(); ?>

git tag -a V0.1 -m „First really good version“. Die Liste aller Tags können Sie mit git tag ohne Angabe von Parametern abfragen. Das war doch einfach und schmerzfrei, oder?!

Wir haben jetzt vor den nun folgenden Änderungen am Projekt ein Tag vergeben, das sich auf einen bestimmten Stand im Repository bezieht. Entwickler A, der das originale Repository bereitgestellt hat und auf Klon testapp-one arbeitet, kennt dieses Tag noch nicht und wird auch erstmal nichts davon erfahren. Entwickler B macht jetzt einige Änderungen und baut schonmal fleißig an Version V0.2 weiter. Hierzu können wir einfach ein paar Verzeichnisse und Dateien anlegen:

$ mkdir -p src/com/tectalic/util
$ vim src/com/tectalic/util/Echo.java

Der Inhalt der Klasse Echo ist der Renner in der Entwicklung und sieht folgendermaßen aus:

package com.tectalic.util;

public class Echo {
   public static String echo(String input) {
      return input;
   }
}

Zugegebenermaßen ist es nicht wirklich aufregend, aber hier geht es um Git und nicht um Java. Eine weitere Abfrage des Status mit Git zeigt folgende Ausgabe:

$ git status
# On branch master
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#  src/
nothing added to commit but untracked files present (use "git add" to track)

Aha, wir bekommen auch noch mitgeteilt, dass wir ein paar Dinge mit git add hinzufügen müssen, wenn wir eine Versionierung wünschen. Nichts leichter als das:

$ git add .
$ git commit -am "New Echo Impl"
[master f672261] New Echo Impl
 1 files changed, 7 insertions(+), 0 deletions(-)
 create mode 100644 src/com/tectalic/util/Echo.java

Wenn Sie möchten, können Sie diesen Stand nun mit einem Tag versehen und pushen. Entwickler A kann dann von Ihnen aufgefordert werden, die gemachten Änderungen mit git pull zu übernehmen. Der übliche Zyklus bewegt sich also zwischen clone, push und pull. Es gibt noch unzählige weitere Möglichkeiten, die aus Platzgründen hier nicht erklärt werden können. Die vorherigen Erläuterungen sollten auch lediglich einen kurzen Appetizer auf Git darstellen. Wenn Sie zuvor mit Subversion gearbeitet haben, wird Ihnen sicher das eine oder andere aufgefallen sein, was in Git anders ist. Der folgende Abschnitt beschreibt nun den Bereich der sich komplett von Systemen wie Subversion unterscheidet.

Die eigentliche Revolution

Soweit sollten die Erklärungen zu den Grundlagen von Git reichen. Bisher war das alles auch schon aus Subversion bekannt und nichts hat die Revolution sichtbar gemacht. Gut, anstelle eines zentralen Repositories wird das ganze verteilt. Wahnsinn, aber wo ist die eigentliche Umkehr vom Bekannten? Das Stichwort heißt hier „Branches“. Wenn Sie bereits Bücher oder Artikel zu Subversion gelesen haben, wird Ihnen aufgefallen sein, dass auch dort die Anlage von Repositories und das Aus- und Einchecken von Dateien und Verzeichnissen als Erstes erklärt wird. Erst später, wenn der Autor glaubt, dass der Leser alles bisherige verstanden hat, geht es ans Eingemachte: das Branching. Braucht man ja nicht so oft, glauben Sie vielleicht. Ist auch viel zu kompliziert, denkt da der ein oder andere. Irgendwie hat ja jeder Recht, aber mit Git rückt das Branching in den Bereich der Grundlagen und wird fast zum Kinderspiel, weil Git auf diesen Prinzipien aufbaut. Also, schauen wir uns genauer an, wie die typischen Workflows mit Git aussehen können. Workflows eben, in denen oft und gerne gebrancht und gemerget wird.

Grundsätzlich kennen Entwickler die folgenden Bereiche: Es gibt einen Releasebereich, in dem getaggte Releases eines Projekts liegen. Dann gibt es einen Branch für die Entwicklung (Development) und einen für die Hotfixes, falls wider erwarten doch noch Fehler in der Software entdeckt werden. Wenn man im Team auch noch einen Versionsmanagergott hat, kann man auch noch Branches für Features einführen, aber was ist, wenn der Profi mal im Urlaub ist? Scherz beiseite, sehen wir uns das Ganze einmal als Grafik an (Abb. 1). Da ist zu erkennen, dass insgesamt vier Branches im Repository über die Zeit geführt werden (Tabelle 1).

Abb. 1: Eine Sammlung typischer Branches und Worfklows entlang der Zeitachse

Abbildung 1 zeigt das fertige Schaubild mit allen Branches, die wir sinnvollerweise gebrauchen können. Um zu verstehen, wie alles zusammenhängt und wie wir das Ganze mit Git im Alltag nutzen können, sollen die nächsten Seiten den Aufbau erklären.