Linus Torvalds persönlich schneiderte seinem Betriebssystem das Versionskontrollsystem Git auf den Leib. Damit lässt sich aber nicht nur der Kernel verwalten, Sie können damit auch Ihre eigene Projekte pflegen.

Kernel-Guru Greg Kroah-Hartmann hat fleißig gezählt: Im Jahr 2007 wuchs der Linux Kernel am Tag im Schnitt um 4500 Zeilen Quelltext – mittlerweile dürften es eher noch mehr sein. Um den Überblick über den Code zu behalten, verwenden die Kernel-Entwickler Git [1]. Dabei handelt es sich um ein sogenanntes Version Control System (VCS), das im Prinzip ähnlichen Systemen wie CVS (Concurrent Versions System, [2]) oder SVN (Subversion [3]) entspricht. Allerdings ist Git, verglichen mit diesen Werkzeugen, wesentlich mächtiger – und komplizierter.

Wenn Sie auf der Suche nach einer Versionsverwaltung für Ihr eigenes Softwareprojekt sind, ist Git sicher einen Blick wert. Dieser Artikel verschafft Ihnen einen Überblick über die grundlegenden Funktionen der Torvaldsschen Erfindung und verrät Ihnen, wie Sie eigene Repositories anlegen und verwenden oder auf jene anderer Entwickler zugreifen und deren Änderungen in Ihr eigenes Git-Verzeichnis übernehmen. Einen historischen Überblick über die Versionskontrolle des Linux-Kernels im Allgemeinen und von Git im Speziellen zeigt der Kasten “Git: Not macht erfinderisch”.

Los geht’s

Als Anschauungsobjekt für diesen Artikel dient der Linux-Kernel. Sie erfahren, wie Sie auf einem Server ein Repository auf Grundlage des offiziellen Linux-2.6-Repositories erstellen und wie Sie einen lokalen Checkout dieses Repositories erstellen, Modifikationen vornehmen und diese zurück in das Repository auf dem Server spielen. Git funktioniert dezentral, was den Entwicklern ermöglicht, jederzeit mit einer lokalen Kopie eines Repositories zu arbeiten. Damit auch andere etwas davon haben, sollten Sie die Änderungen aber in einem Repository veröffentlichen.

Git ist seit Längerem Bestandteil der großen Distributionen wie OpenSuse, Ubuntu, Fedora oder Mandriva. Entsprechend verwenden Sie zur Installation den Paketmanager Ihrer Distribution. Installieren Sie darüber hinaus auch das Git-Webfrontend git-web. Um die korrekte Installation zu prüfen, geben Sie den Aufruf git help in der Konsole ein, worauf das Programm die Hilfeseite anzeigt (Abbildung 1).

git help auf der Kommandozeile diese Ausgabe.” width=”300″ height=”171″ /> Abbildung 1: Nach der Installation von Git zeigt die Eingabe von git help auf der Kommandozeile diese Ausgabe.

Bevor Sie Repositories anlegen oder modifizieren, müssen Sie Git erst einmal grundlegend konfigurieren. Dazu gehört die Angabe Ihres Namens und Ihrer E-Mail-Adresse, die später zum festen Bestandteil eines jeden Git-Commits werden. Optional teilen Sie Git mit, welchen Editor Sie bevorzugen. Die notwendigen Befehle zeigt Listing 1. Git legt damit in Ihrem persönlichen Verzeichnis eine Datei namens .gitconfig an, die diese Angaben enthält.

$ git config --global user.name "Ihr Name"
$ git config --global user.email ihrname@beispiel.de
$ git config --global core.editor vim
$ git config --global color.branch "auto"
$ git config --global color.status "auto"
$ git config --global color.diff "auto"

Den Git-Server installieren

Dieser Artikel geht davon aus, dass Sie ein öffentliches Git-Verzeichnis anlegen, auf das prinzipiell jedermann lesend zugreifen darf. Entwickler mit eigenem Account auf dem Server dürfen außerdem ihre Änderungen in Form von Commits in das Git-Repository einspielen. Damit das klappt, brauchen Sie zunächst den Git-Server.

Legen Sie einen Ordner an, der Ihre Git-Repositories enthält, etwa /home/git, und bestimmen Sie als besitzende Gruppe und User jeweils git. Sofern noch nicht vorhanden, installieren Sie danach einen Inetd-Daemon und öffnen dessen Konfiguration /etc/inetd.conf. Dort tragen Sie die folgende Zeile ein:

git stream tcp nowait gitserver /usr/bin/git-daemon git-daemon --inetd --verbose --base-path=/home/git

Damit ist der Git-Daemon eingerichtet. Zugriff auf die Repositories erhalten Sie und andere später über die URL http://server/name. Heißt ein Repository also linux-2.6-local und der Hostname des Servers git.example.org, wäre die vollständige URL für das Repository entsprechend http://git.example.org/linux-2.6-local. Der zugehörige Ordner im Dateisystem wäre dann /home/git/linux-2.6-local.

Beachten Sie: Je nach verwendeter Distribution ist die Funktion export-all entweder aktiv oder abgeschaltet. Ist sie aus, führt das dazu, dass der Git-Daemon nicht alle Ordner in /home/git automatisch erfasst. Um sicherzustellen, dass der Git-Daemon ein Repository immer exportiert, legen Sie im Ordner des Repositories auf Ihrem Server die Datei git-daemon-export-ok an.

Basisverzeichnis

In diesem Beispiel landet das Verzeichnis, in dem Sie und Ihre Kollegen entwickeln, auf einem Server – diese Rolle kann auch Ihr heimischer Rechner übernehmen. Die Firewall darf dazu den Git-Port 9418 nicht blockieren. Sofern Sie hinter einem Router arbeiten, gilt es darüber hinaus, den Port auf Ihren Rechner weiterzuleiten: Andernfalls erhalten Anwender außerhalb Ihres lokalen Netzes keinen Zugriff auf Git. Zum Verwenden des Git-Webinterfaces benötigen Sie ferner einen Webserver, idealerweise Apache.

Um den den aktuellen Kernel-Zweig von Linus Torvalds [4] in das Verzeichnis /home/git/linux-2.6-local zu klonen (Abbildung 2), geben Sie den Befehl aus der ersten Zeile von Listing 2 ein. Anschließend legen Sie in der Datei description im Repository-Ordner eine Beschreibung des Projekts an (Listing 2, Zeile 2)

linux-2.6-Verzeichnis.” width=”300″ height=”59″ /> Abbildung 2: In diesem Beispiel entsteht auf dem Server ein Klon von Linus Torvalds’ linux-2.6-Verzeichnis.

$ git clone -n --bare git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6-local
$ echo "Entwicklungskernel und eigene Patches" > linux-2.6-local/description

Beachten Sie, dass die Quellen im Kernel-Git derzeit mehrere hundert MByte umfassen. Das Klonen des Ordners dauert entsprechend je nach Bandbreite Ihres Internetanschlusses einige Zeit. Im nächsten Schritt legen Sie auf Ihrem lokalen System eine Kopie Ihres Repositories an und bearbeiten diese.

Lokale Arbeitskopie

Um Git auf dem heimischen Rechner als Client und Server gleichzeitig zu betreiben, müssen Sie nun den Abzug des Zweigs aus dem Verzeichnis /home/git erneut klonen. Anderenfalls wäre der Git-Server nicht in der Lage, Ihre Änderungen korrekt ins Repository einzupflegen. Sie verhalten sich diesem gegenüber entsprechend wie ein externer Anwender. Heißt der Hostname des Servers git.example.org, lautet die Anweisung:

$ git clone ssh://git.example.org/linux-2.6-local linux-2.6-local

Danach nehmen Sie mit Git auf dem Server keine direkten Veränderungen mehr an Ihrem Repository vor. Diese stoßen zukünftig nur noch Entwickler an, die ihre Modifikationen von lokalen Kopien auf den Server hochladen.

Zu einer häufig wiederkehrenden Aufgabe gehört in unserem Beispiel der Abgleich des Linux-Hauptentwicklungszweiges mit dem Repository auf Ihrem Server. Das liegt vor allem daran, dass sich dieses Repository permanent ändert und sie damit den jeweils aktuellsten Stand besitzen. Dieser Abgleich der lokalen Daten mit dem Upstream-Repository heißt “pull”, das Hochladen eigener Modifikationen nennt sich “push”.

Folgender Befehl, im lokalen Repository-Verzeichnis ausgeführt, legt Linus Torvalds’ Git-Repository als Quelle für Veränderungen in Ihrem lokalen Repository fest:

$ git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

Der Befehl git fetch -v linus aktualisiert zukünftig Ihre lokale Arbeitskopie. Wenn sich also zwischen dem Klonen des Repositorys am Server und auf Ihrer Workstation etwas verändert, würden Sie diese Änderungen jetzt bereits sehen. Die Befehle git push -v origin und git pull bringen das Repository auf Ihrem Server auf den aktuellen Stand. Damit synchronisieren Sie sowohl Ihre lokale Arbeitskopie als auch das Repository auf dem Server.

Self made

Möchten Sie mit Git ein eigenes Projekt verwalten, benötigen Sie andere Kommandos, um auf dem Server ein zentrales Repository anzulegen. Statt der genannten Anweisung clone legen Sie ein Repository für das Programm helloworld analog zur Anleitung oben mit der Befehlsfolge aus Listing 3 an, die sie im Ordner helloworld ausführen.

$ git init
$ git add .
$ cd /home/git && git clone -bare /Pfad/zum/helloworld-Ordner helloworld
$ git update-server-info
$ cd /home/git/helloworld && touch git-daemon-export-ok
$ cd /Pfad/zum/helloworld-Ordner
$ git remote add origin /home/git/helloworld
$ git push origin master

Die ersten beiden Befehle initiieren Git-Metadaten im Ordner der entpackten Quellen von helloworld, der dritte erstellt auf dieser Grundlage ein echtes Git-Repository im Verzeichnis /home/git/helloworld. Die Befehle in den Zeilen 4 und 5 sorgen dafür, dass der Git-Server das neue Repository exportiert.

Die drei letzten Befehle legen als zukünftige Quelle für die Sourcen von helloworld in dessen Quelltextordner Ihr gerade erstelltes Repository fest und kopieren die dort zu enthaltenen Dateien und Verzeichnisse erstmalig in das Repository. Auf der Workstation handhaben Sie dieses Verzeichnis genauso, wie zuvor beschrieben den Linus-Kernel – mit der Ausnahme, dass Sie das Tracken des Upstream-Zweiges von Linus Torvalds nicht konfigurieren können.

Arbeit mit Repositories

Um eigene Kernel-Patches zu entwickeln, empfehlen sich zwei Maßnahmen: Zunächst sorgen Sie dafür, dass die lokale Kopie Ihres Repositories die aktuelle stabile Kernel-Version enthält. Zum anderen nehmen Sie Veränderungen nicht im Default-Branch vor, sondern erstellen Ihren eigenen Zweig.

Der Aufruf git checkout -b my-2.6.34 v2.6.34 erstellt einen Branch namens my-2.6.34, der als Grundlage den Git-Stand mit dem Tag v2.6.34 verwendet. Hätten Sie statt 2.6.34 die Version 2.6.33 angeben, würden Sie die Dateien dieser Kernel-Version sehen. Bisher sind die Änderungen nur in Ihrem lokalen Ordner vorhanden. Schieben Sie diese jetzt mit git push -v origin my-2.6.34 in Ihr Server-Repository.

Achten Sie beim Bearbeiten darauf, dass Sie im Idealfall nach jeder Änderung den Befehl git commit -m Logeintrag vornehmen. Die Log-Einträge sollten Sie sinnvoll und vor allem aussagekräftig benennen, da das später die Fehlersuche enorm erleichtert. Vergessen Sie im Anschluss an die Änderungen nicht, diese mit dem Befehl git push -v origin an das Repository auf Ihrem Server zu übermitteln.

Falls Sie neue Dateien in die Versionskontrolle mit Git einfügen oder verwaiste Dateien löschen möchten, führen Sie vor dem Commit die Befehle git add Datei (Hinzufügen) oder git rm Datei (löschen) aus. Um den Stand Ihres Git-Repositories mit einer Versionsnummer zu versehen, setzten Sie mit git tag 2.6.34-local1 das Tag 2.6.34-local1. Damit kennzeichnen Sie den aktuellen Status.

Auch wenn Sie nur bestimmte Dateien im Kernel-Zweig verändern, möchten Sie sicher auch für die anderen Teile weiterhin die Updates von Linus Torvalds erhalten. Mit dem Befehl git pull bringen Sie die lokale Kopie Ihres Repositories auf den aktuellen Stand:

$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

Wieder gilt: Vergessen Sie nicht, die gerade erhaltenen Änderungen von Linus auch in Ihr Server-Repository zu pushen. Übrigens: Es schadet nicht, Ihr lokales Repository mittels git pull http://git.example.org/linux-2.6-local mit dem Inhalt Ihres eigenen Server-Repositories abzugleichen, falls Sie über einen längeren Zeitraum hinweg nicht an der Entwicklung teilgenommen haben. Pullen und pushen funktioniert bei Git grundsätzlich in alle Richtungen und von allen Branches und Tags aus.

Gitweb

Um die grundlegenden Eigenschaften des Git-Webinterfaces einzurichten, öffnen Sie die Konfigurationsdatei /etc/gitweb.conf in einem Texteditor und fügen die folgenden beiden Zeilen hinzu (oder ändern bereits vorhandene ab):

$projectroot = "/home/git/";
$projects_list = "/home/git/project_list";

In /home/git/project_list schreiben Sie die Repositories, die Gitweb anzeigen soll. Die Datei folgt der Syntax: linux-2.6-local mgl. Dabei ist linux-2.6-local der Name des Repositories und mgl der Name der Person, der das Repository gehört. Um mit Anderen zusammenzuarbeiten, sorgen Sie nun noch dafür, dass diese Gitweb von außen erreichen. Steht das “DocumentRoot” von Apache auf /var/www/, gehen Sie wie folgt vor:

$ mkdir /var/www/gitweb
$ cd /var/www/gitweb && ln -s /usr/share/gitweb/* .

Sie erreichen Gitweb (Abbildung 3) nun über die URL http://git.example.org/gitweb/. Die Web-GUI gestattet Ihnen einen schnellen Überblick über aktuelle Veränderungen und Commits und erweist sich beim Auslesen von Logs als sehr nützlich. 

Abbildung 3: Gitweb ist ein Webfrontend für Git und hilft Ihnen, den Überblick zu behalten.

Git: Not macht erfinderisch

Linux wurde nicht von Anfang an in einem System zur Quelltextverwaltung gepflegt. Bis ins Jahr 2002 änderte Linus Torvalds (Abbildung 4) den gesamten Quelltext ausschließlich in Form von Patches. Dieser Workflow erwies sich allerdings im Hinblick auf das Entwicklungsmodell von Linux als immer unpraktikabler. Denn soviel war klar: Der Kernel-Maintainer konnte sich unmöglich alleine weiterhin um den gesamten Kernel-Quelltext kümmern.Deshalb übernahmen sogenannte Subsystem-Maintainer die Verantwortung für einzelne Teilbereiche des Kernels. Sie sichteten den Code und und leiteten aus ihrer Sicht brauchbare Vorschläge an Torvalds weiter.

Abbildung 4: Linux-Erfinder Linus Torvalds schneiderte dem Linux-Kernel ein eigens Versionskontrollsystem auf den Leib.

Für ihn und seine Zuarbeiter wäre es allerdings auf Dauer in hohem Maße unpraktikabel gewesen, ständig Patches hin- und herzuschicken und diese direkt auf Ordner mit entpackten Quellen anzuwenden. Deswegen beschloss Linus Torvalds 2002, das kommerziellen Versionskontrollsystem Bitkeeper für den Linux-Kern einzusetzen. Dessen Hersteller erlaubte zwar das kostenlose Benutzen der Anwendung, jedoch nur, solange der Anwender nicht an einem anderen Versionskontrollsystem mitarbeitete. Viele Entwickler der “alten Garde” empfanden diese Einschränkung als unzumutbar.

Andrew Tridgell, eigentlich bekannt als Samba-Entwickler, begann daraufhin mit der Entwicklung der Alternative Sourcepuller, die zu Bitkeeper kompatibel war. Er gab an, selbst niemals Bitkeeper verwendet zu haben. Bitkeeper-Chef Larry McVoy nannte Tridgells Verhalten trotzdem “unanständig” und behauptete, es handele sich um Reverse-Engineering. Neue Bitkeeper-Versionen standen in der Folge nicht mehr kostenlos zur Verfügung. Torvalds brauchte eine Alternative zum gerade erst zwei Jahre verwendeten Bitkeeper.

Er testete daraufhin alle gängigen VCS und stellte dabei fest, dass keines davon effizient genug erschien. Daraufhin beschloss er kurzerhand, selbst ein passendes System zu entwickeln. Bald darauf, im April 2005, veröffentlichte Torvalds die erste Alpha-Version von Git. Am 16. Juni 2005 erschien Linux 2.6.12, das bereits mit dem neuen System verwaltet wurde. Kurz darauf fingen andere Entwickler an, Patches für Git zu senden – die Entwicklung verselbständigte sich. Linus Torvalds übergab die Pflege des Projekts im Juli 2005 schließlich an Junio Hamano, der sich seither darum kümmert.

Git hat mittlererweile viele andere Versionskontrollsysteme verdrängt und gehört zu den meistbenutzten Anwendungen seiner Art. Die aus der Not heraus entstandene Lösung etablierte sich praktisch über Nacht zur dominierenden Lösung zur Versionskontrolle. Inzwischen existieren außerdem diverse Tools und Konnektoren, um Git mit anderen VCS zu verknüpfen. So erlaubt Git das Ansprechen von Mercurial- und SVN-Repositories sowie das gegenseitige Befüllen.