2008 ist ein besonders starkes Jahr für Git: Im Februar stellte die Firma Logical Awesome die Website Github vor, auf der Programmierer Projekte in Git hosten lassen können - für freie Software-Projekte kostenlos. Das führte nicht nur die Rails-Entwickler dazu, ihren Quellcode in Zukunft in Git zu verwalten: Auch ein Microsoft-Entwickler ließ sich dazu hinreißen, den Einsatz von Github in der Entwicklung von IronRuby anzukündigen. Auf eine noch größere Verbreitung von Git lässt die kürzlich veröffentlichte Version 1.6.0 hoffen. Diese enthält erstmals alle Anpassungen, die das System unter Windows lauffähig machen.
Konsequent dezentral
Der Einstieg in Git ist dank der stetig wachsenden Dokumentation nicht schwierig, auch wenn sich langjährige CVS- und Subversion-Benutzer auf einen Paradigmenwechsel einstellen müssen: Git hat hervorragende Netzwerkfähigkeiten, zentralen Server gibt es aber keinen. Während Benutzer der beiden letztgenannten Systeme bei jedem Zugriff auf die Projektgeschichte über TCP/IP mit dem Repository kommunizieren müssen, läuft bei verteilten Systeme wie Git alles lokal ab: Jede Arbeitskopie enthält eine vollständige Aufzeichnung aller Änderungen am Code, was nicht nur das Ausgeben von Patches zwischen zwei Revisionen in unter einer Sekunde ermöglicht sondern insgesamt für bequemes Arbeiten im Offline-Zustand sorgt.
Commits, Trees, Blobs und Tags
Das grundlegende Speichermodell ist relativ unkompliziert: Im Wurzelverzeichnis eines mit Git verwalteten Projekts befindet sich ein Unterverzeichnis namens ".git/". Darin gibt es einen weiteren Ordner "objects/", in dem Objekte vier verschiedener Arten liegen (Abbildung 1). Diese Objekte sind Zlib-komprimierte Dateien, die mittels ihrer SHA-1-Hashes angesprochen werden. Durch diesen konsequenten Einsatz kryptographischer Prüfsummen wird sichergestellt, dass kein Angreifer die Projektgeschichte böswillig verändern kann; Revisionsnummern nach dem Muster beispielsweise von SVN geben stellen das nicht sicher.
Git speichert die gesamte Projektchronik in Objekten, von denen es vier Sorten gibt.
Der einzige Objekttyp, mit dem der durchschnittliche Git-Benutzer täglich zu tun hat, ist der Commit. Commits sind Momentaufnahmen eines ganzen Projekts oder, anders ausgedrückt, Punkte in der Quellcode-Historie. Jeder Commit besteht aus einem beschreibenden Stück Text (die "commit message"), Information über Zeit und Autor, Verweisen auf beliebig viele übergeordnete Commits ("parents"), sowie einem Zeiger auf einen Tree.
Solche Tree-Objekte repräsentieren Verzeichnisse. Sie enthalten eine Liste von Dateinamen, wobei jedem davon ein Unter-Tree oder Blob zugewiesen ist. Ein solches Blob speichert Rohdaten, beliebige Dateiinhalte.
Beim vierten und seltensten Objekttyp handelt es sich um das Tag. Die Übersetzung aus dem Englischen verrät, dass es sich um eine Art Etikett handelt. Ein Tag verweist auf ein Objekt und versieht es mit einem Namen sowie einer Botschaft, der "tag message". Haupteinsatzgebiet ist die Deklaration von Releases: Ein "v0.1" benanntes Tag wird beispielsweise auf ein Commit-Objekt zeigen, das die Version 0.1 enthält. Die Botschaft kann eine GPG-Signatur des Autors sein, womit dieser seinen Segen genau genommen nicht nur unter diesen einen Commit setzt, sondern die gesamte Quellcode-Historie bis zu diesem Punkt absegnet. Das machen die bereits erwähnten SHA-1-Prüfsummen möglich.
