Mal was Anderes: Git

Das alte RCS hatte gegenüber allen hypermodernen Client-Server-SCMs einen großen Vorteil: Wenn man mal eben eine Datei versionieren will, sagt man einfach co dateiname. Besser noch, man versioniert die Datei im Emacs, und hat keine Sorgen mehr. Das ist zwar nicht praktikabel für Multimillionendateienprojekte, wie sie heute die Regel sind, aber perfekt für Konfigurationsdateien oder "Microprojekte", also Tools, die man nebenbei mal so schreibt.

Allerdings gibt es gute Gründe, RCS nicht zu verwenden. Zusammengefaßt: Aus heutiger Sicht kann RCS nicht mehr als SourceSafe. Na schön, laut der aktuellen Dokumentation von VSS kann VSS mittlerweile mehr als RCS (nämlich Verzweigen und Zusammenführen, bekannt als Branchen und Mergen). Wie dem auch sei, RCS lebt, solange es keine Alternative für solche Microprojekte gibt.

Und hier ist sie: Git, das Fast Version Control System. Git ist anders als Subversion, anders als RCS; es ist zusammen mit Mercurial eine neue Kategorie von SCM: verteiltes SCM. Im Gegensatz zu einem Client-Server-SCM, bei dem das Repository mit allen versionierten Dateien auf einem zentralen Server liegt, hat bei einem verteilten SCM jeder Client ein vollwertiges Repository lokal vorliegen. Damit hat man jederzeit offline Zugriff auf die komplette verzweigte History des Projektes, was ein großer Vorteil ist, wenn man aus irgendwelchen Gründen tatsächlich offline arbeiten muß.

Ein Git-Repository ist schnell aufgesetzt: alles, was man braucht, ist ein Wurzelverzeichnis. Dann reicht ein git-init, und schon kann man Dateien versionieren. In der Vergangenheit waren verschiedene Aufsätze zu Git populär (z.B. Cogito), um die Arbeit mit Git zu vereinfachen. Aktuell wird Git aber als nutzerfreundlich genug angesehen, sodaß diese Aufsätze als "deprecated" gelten.

Gilt es nun, eine lokale Arbeitskopie zu erstellen, wird bei einem verteilten SCM ein beliebiges vorhandenes Repository geklont. Bei Git klont man in der Regel das Repository, in das man seine Änderungen wieder einspielen möchte. Auch das ist sehr einfach: Ein git-clone erstellt ein Verzeichnis mit dem Namen des Repositories und packt dort den Inhalt des Repositories aus. Wechselt man nun in das neue Verzeichnis, kann man sofort einen Versionsbaum des Repositories begutachten, indem man gitk sagt. Gitk ist ein Tcl/Tk Frontend zum kommandozeilenbetriebenen Git; erwähnenswert ist noch git-gui, ein weiteres Frontend, welches alle praktischen Arbeiten in Git in einer GUI zusammenfaßt.

Der Rest ist schnell erzählt: Neue Dateien werden per git-add hinzugefügt, alte werden mit git-rm gelöscht oder per git-mv umbenannt/verschoben, ein Changeset wird per git-commit ins (lokale) Repository geschrieben. Updates vom Upstream-Repository besorgt man sich per git-pull, seine eigenen Änderungen schiebt man per git-push wieder zurück (hierfür wird i.d.R. ein SSH-Zugang benötigt). Branches werden per git-branch angelegt (oder einfacher per git-checkout -b ), zwischen den Branches kann per git-merge gemerged werden. Zuletzt kann ein erreichter Zustand per git-tag gelabelt werden (Bonbon: per git-tag -s kann der Stand PGP/GPG-signiert werden). Zu einem beliebigen Stand im Repository gelangt man wieder per git-checkout, was damit zu einem der wichtigsten Befehle mutiert.

Damit ist die Grundfunktionalität eines SCM abgedeckt. Git kann noch eine ganze Menge mehr, aber das kann man sich ansehen, wenn man wirklich mal ein größeres Projekt unter Git verwaltet. Was noch fehlt ist eine vernünftige Integration in Eclipse (das Java GIT/Eclipse GIT Plugin habe ich nicht zur Zusammenarbeit bewegen können).

Das ist alles viel zu umständlich und generell nicht praktikabel? Nun, obwohl ich als bekennender Apple-User natürlich (!) BSD vorziehe, wird der Linux-Kernel unter Verwendung von Git weiterentwickelt. Das scheint ja erstmal zu funktionieren.

[Update 2009-01-14]

Die offizielle Homepage von git ist umgezogen. Git firmiert nun unter http://git-scm.com.

[/Update 2009-01-14]