10.2 Git Internals - Git-Objekte

Der nächste Git-Objekttyp, den wir untersuchen werden, ist der Tree (Baum), der das Problem der Speicherung des Dateinamens löst und es Ihnen ermöglicht, eine Gruppe von Dateien zusammen zu speichern. Git speichert Inhalte ähnlich wie ein UNIX-Dateisystem, aber etwas vereinfacht. Alle Inhalte werden als Tree- und Blob-Objekte gespeichert, wobei Trees UNIX-Verzeichniseinträgen entsprechen und Blobs mehr oder weniger Inodes oder Dateiinhalten. Ein einzelnes Tree-Objekt enthält einen oder mehrere Einträge, von denen jeder der SHA-1-Hash eines Blobs oder Subtrees mit seinem zugehörigen Modus, Typ und Dateinamen ist. Nehmen wir beispielsweise an, Sie haben ein Projekt, bei dem der aktuellste Tree wie folgt aussieht

Die Syntax master^{tree} gibt das Tree-Objekt an, auf das der letzte Commit Ihres master-Branches zeigt. Beachten Sie, dass das Unterverzeichnis lib kein Blob ist, sondern ein Zeiger auf einen anderen Tree

Konzeptionell sehen die von Git gespeicherten Daten wie folgt aus

Sie können Ihre eigenen Trees relativ einfach erstellen. Git erstellt normalerweise einen Tree, indem es den Zustand Ihrer Staging-Area oder Ihres Index nimmt und daraus eine Reihe von Tree-Objekten schreibt. Um also ein Tree-Objekt zu erstellen, müssen Sie zuerst einen Index einrichten, indem Sie einige Dateien staged. Um einen Index mit einem einzigen Eintrag zu erstellen – der ersten Version Ihrer Datei test.txt –, können Sie den Plumbing-Befehl git update-index verwenden. Sie verwenden diesen Befehl, um die frühere Version der Datei test.txt künstlich zu einer neuen Staging-Area hinzuzufügen. Sie müssen die Option --add übergeben, da die Datei noch nicht in Ihrer Staging-Area vorhanden ist (Sie haben noch keine Staging-Area eingerichtet) und --cacheinfo, da sich die hinzuzufügende Datei nicht in Ihrem Verzeichnis, sondern in Ihrer Datenbank befindet. Dann geben Sie den Modus, die SHA-1 und den Dateinamen an

In diesem Fall geben Sie einen Modus von 100644 an, was bedeutet, dass es sich um eine normale Datei handelt. Andere Optionen sind 100755, was bedeutet, dass es sich um eine ausführbare Datei handelt; und 120000, was einen symbolischen Link angibt. Der Modus stammt von normalen UNIX-Modi, ist aber viel weniger flexibel – diese drei Modi sind die einzigen, die für Dateien (Blobs) in Git gültig sind (obwohl andere Modi für Verzeichnisse und Submodule verwendet werden).

Nun können Sie git write-tree verwenden, um die Staging-Area in ein Tree-Objekt zu schreiben. Es ist keine Option -w erforderlich – das Aufrufen dieses Befehls erstellt automatisch ein Tree-Objekt aus dem Zustand des Index, falls dieser Tree noch nicht existiert

Sie können auch mit demselben git cat-file-Befehl, den Sie zuvor gesehen haben, verifizieren, dass es sich um ein Tree-Objekt handelt

Sie werden nun einen neuen Tree mit der zweiten Version von test.txt und einer neuen Datei erstellen

Ihre Staging-Area enthält nun die neue Version von test.txt sowie die neue Datei new.txt. Schreiben Sie diesen Tree aus (der den Zustand der Staging-Area oder des Index in einem Tree-Objekt aufzeichnet) und sehen Sie sich an, wie er aussieht

Beachten Sie, dass dieser Tree sowohl Dateieinträge hat als auch dass die SHA-1 für test.txt die "Version 2" SHA-1 von früher ist (1f7a7a). Nur zum Spaß werden Sie den ersten Tree als Unterverzeichnis in diesen einfügen. Sie können Trees mit git read-tree in Ihre Staging-Area lesen. In diesem Fall können Sie einen vorhandenen Tree als Subtree in Ihre Staging-Area lesen, indem Sie die Option --prefix mit diesem Befehl verwenden

Wenn Sie ein Arbeitsverzeichnis aus dem gerade geschriebenen neuen Tree erstellen würden, erhielten Sie die beiden Dateien im obersten Level des Arbeitsverzeichnisses und ein Unterverzeichnis namens bak, das die erste Version der Datei test.txt enthielt. Sie können sich die von Git für diese Strukturen enthaltenen Daten wie folgt vorstellen

Wenn Sie alles bisherige durchgeführt haben, verfügen Sie nun über drei Trees, die die verschiedenen Snapshots Ihres Projekts darstellen, das Sie verfolgen möchten, aber das frühere Problem bleibt bestehen: Sie müssen sich alle drei SHA-1-Werte merken, um die Snapshots abrufen zu können. Außerdem haben Sie keine Informationen darüber, wer die Snapshots gespeichert hat, wann sie gespeichert wurden oder warum sie gespeichert wurden. Dies sind die grundlegenden Informationen, die das Commit-Objekt für Sie speichert.

Um ein Commit-Objekt zu erstellen, rufen Sie commit-tree auf und geben einen einzelnen Tree-SHA-1 und die Commit-Objekte an, die ihm direkt vorausgingen, falls vorhanden. Beginnen Sie mit dem ersten Tree, den Sie geschrieben haben

Nun können Sie Ihr neues Commit-Objekt mit git cat-file betrachten

Das Format eines Commit-Objekts ist einfach: Es gibt den Top-Level-Tree für den Snapshot des Projekts zu diesem Zeitpunkt an; die übergeordneten Commits, falls vorhanden (das oben beschriebene Commit-Objekt hat keine Eltern); die Autor-/Commiter-Informationen (die Ihre user.name- und user.email-Konfigurationseinstellungen und einen Zeitstempel verwenden); eine Leerzeile und dann die Commit-Nachricht.

Als Nächstes schreiben Sie die anderen beiden Commit-Objekte, die jeweils auf den direkt vorangegangenen Commit verweisen

Jedes der drei Commit-Objekte verweist auf einen der drei erstellten Snapshot-Trees. Seltsamerweise haben Sie jetzt eine echte Git-Historie, die Sie mit dem Befehl git log anzeigen können, wenn Sie ihn auf den letzten Commit-SHA-1 anwenden

Erstaunlich. Sie haben gerade die Low-Level-Operationen ausgeführt, um eine Git-Historie aufzubauen, ohne die Front-End-Befehle zu verwenden. Dies ist im Wesentlichen das, was Git tut, wenn Sie die Befehle git add und git commit ausführen – es speichert Blobs für die geänderten Dateien, aktualisiert den Index, schreibt Trees aus und schreibt Commit-Objekte, die auf die Top-Level-Trees und die unmittelbar vorangegangenen Commits verweisen. Diese drei Haupt-Git-Objekte – der Blob, der Tree und der Commit – werden zunächst als separate Dateien in Ihrem .git/objects-Verzeichnis gespeichert. Hier sind alle Objekte im Beispielverzeichnis jetzt, mit Kommentaren, was sie speichern

Wenn Sie allen internen Zeigern folgen, erhalten Sie einen Objektgraphen, der etwa so aussieht

Wir haben bereits erwähnt, dass mit jedem Objekt, das Sie in Ihre Git-Objektdatenbank committen, ein Header gespeichert wird. Nehmen wir uns eine Minute Zeit, um zu sehen, wie Git seine Objekte speichert. Sie werden sehen, wie Sie interaktiv in der Ruby-Skriptsprache ein Blob-Objekt speichern – in diesem Fall den String "what is up, doc?".

Sie können den interaktiven Ruby-Modus mit dem Befehl irb starten

Git erstellt zuerst einen Header, der damit beginnt, den Objekttyp zu identifizieren – in diesem Fall ein Blob. Zu diesem ersten Teil des Headers fügt Git ein Leerzeichen, gefolgt von der Größe des Inhalts in Bytes, und ein abschließendes Nullbyte hinzu

Git verkettet den Header und den ursprünglichen Inhalt und berechnet dann die SHA-1-Prüfsumme dieses neuen Inhalts. Sie können den SHA-1-Wert eines Strings in Ruby berechnen, indem Sie die SHA1-Digest-Bibliothek mit dem Befehl require einschließen und dann Digest::SHA1.hexdigest() mit dem String aufrufen

Vergleichen wir das mit der Ausgabe von git hash-object. Hier verwenden wir echo -n, um das Hinzufügen eines Zeilenumbruchs zur Eingabe zu verhindern.

Git komprimiert den neuen Inhalt mit zlib, was Sie in Ruby mit der zlib-Bibliothek tun können. Zuerst müssen Sie die Bibliothek anfordern und dann Zlib::Deflate.deflate() auf den Inhalt anwenden

Schließlich schreiben Sie Ihren zlib-deflatierten Inhalt in ein Objekt auf der Festplatte. Sie ermitteln den Pfad des zu schreibenden Objekts (die ersten beiden Zeichen des SHA-1-Wertes als Unterverzeichnisname und die letzten 38 Zeichen als Dateiname innerhalb dieses Verzeichnisses). In Ruby können Sie die Funktion FileUtils.mkdir_p() verwenden, um das Unterverzeichnis zu erstellen, falls es noch nicht existiert. Öffnen Sie dann die Datei mit File.open() und schreiben Sie den zuvor zlib-komprimierten Inhalt mit einem write()-Aufruf auf dem resultierenden Dateihandle in die Datei

Überprüfen wir den Inhalt des Objekts mit git cat-file

Das war's – Sie haben ein gültiges Git-Blob-Objekt erstellt.

Alle Git-Objekte werden auf die gleiche Weise gespeichert, nur mit unterschiedlichen Typen – anstelle des Strings blob beginnt der Header mit commit oder tree. Auch wenn der Blob-Inhalt fast alles sein kann, sind die Commit- und Tree-Inhalte sehr spezifisch formatiert.