10.2 Git Interna - Git Objekte

Die nächste Art von Git-Objekte, die wir untersuchen, ist der baum, der das Problem des Speicherns des Dateinamens löst und es dir auch ermöglicht, eine Gruppe von Dateien zusammen zu speichern. Git speichert Inhalte auf ähnliche Weise wie ein UNIX-Dateisystem, jedoch etwas vereinfacht. Der gesamte Inhalt wird als Baum- und Blob-Objekte gespeichert, wobei Bäume UNIX-Verzeichniseinträgen entsprechen und Blobs mehr oder weniger Inodes oder Dateiinhalten entsprechen. Ein einzelnes Baumobjekt enthält einen oder mehrere Einträge, von denen jeder der SHA-1-Hash eines Blobs oder Teilbaums mit dem zugehörigen Modus, Typ und Dateinamen ist. Angenommen du hast ein Projekt, in dem der aktuellste Baum folgendermaßen aussieht:

Die master^{tree} Syntax gibt das Baumobjekt an, auf das durch das letzte Commit in deinem master Branch verwiesen wird. Beachte, dass das Unterverzeichnis lib kein Blob ist, sondern ein Zeiger auf einen anderen Baum:

Konzeptionell sehen die von Git gespeicherten Daten ungefähr so aus:

Du kannst ziemlich einfach deinen eigenen Baum erstellen. Git erstellt normalerweise einen Baum, indem es den Status deines Staging-Bereichs oder Index übernimmt und eine Reihe von Baumobjekten daraus schreibt. Um ein Baumobjekt zu erstellen, musst du zunächst einen Index einrichten, indem du einige Dateien bereitstellst. Um einen Index mit einem einzigen Eintrag zu erstellen — der ersten Version Deiner test.txt Datei — kannst du den Basisbefehl git update-index verwenden. Mit diesem Befehl fügst du die frühere Version der Datei test.txt künstlich einem neuen Staging-Bereich hinzu. Du musst die Option --add übergeben, da die Datei in deinem Staging-Bereich noch nicht vorhanden ist (Du hast noch nicht einmal einen Staging-Bereich eingerichtet). --cacheinfo musst du angeben, weil die hinzugefügte Datei sich nicht in deinem Verzeichnis, sondern in deiner Datenbank befindet. Dann gibst du den Modus, SHA-1 und Dateinamen an:

In diesem Fall gibst du den Modus 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 aus normalen UNIX-Modi, ist jedoch 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).

Jetzt kannst du git write-tree verwenden, um den Staging-Bereich in ein Baumobjekt zu schreiben. Es ist keine Option -w erforderlich. Durch Aufrufen dieses Befehls wird automatisch ein Baumobjekt aus dem Status des Index erstellt, wenn dieser Baum noch nicht vorhanden ist:

Du kannst auch überprüfen, ob es sich um ein Baumobjekt handelt, indem du denselben Befehl git cat-file verwendest, den du zuvor gesehen hast:

Du erstellst jetzt einen neuen Baum mit der zweiten Version von test.txt und einer neuen Datei:

Dein Staging-Bereich enthält jetzt die neue Version von test.txt sowie die neue Datei new.txt. Schreibe diesen Baum aus (zeichne den Status des Staging-Bereichs oder des Index für ein Baumobjekt auf) und schau dir an, wie er aussieht:

Beachte, dass dieser Baum beide Dateieinträge enthält und dass der SHA-1 von test.txt der SHA-1 „Version 2“ von früher (1f7a7a) entspricht. Zum rumprobieren füge diesem den ersten Baum als Unterverzeichnis hinzu. Du kannst Bäume in deinem Staging-Bereich einlesen, indem du git read-tree aufrufst. In diesem Fall kannst du einen vorhandenen Baum als Teilbaum in deinem Staging-Bereich einlesen, indem du die Option --prefix mit diesem Befehl verwendest:

Wenn du aus dem soeben erstellten Baum ein Arbeitsverzeichnis erstellst, erhältst du die beiden Dateien in der obersten Ebene des Arbeitsverzeichnisses und ein Unterverzeichnis mit dem Namen bak, das die erste Version der Datei test.txt enthält. Du kannst dir die Daten, die Git für diese Strukturen enthält, so vorstellen:

Wenn du alle oben genannten Schritte ausgeführt hast, verfügst du nun über drei Bäume, die die verschiedenen Schnappschüsse deines Projekts darstellen, die du verfolgen möchtest. Das bisherige Problem bleibt jedoch bestehen: Du müsst dir alle drei SHA-1-Werte merken, um die Schnappschüsse abzurufen. Du hast auch keine Informationen darüber, wer die Schnappschüsse gespeichert hat, wann sie gespeichert wurden oder warum sie gespeichert wurden. Dies sind die grundlegenden Informationen, die das Commit Objekt für dich speichert.

Um ein Commit Objekt zu erstellen, rufe commit-tree auf und gib einen einzelnen Baum SHA-1 an. Gib außerdem an welche Commit Objekte die direkten Vorgänger sind (falls überhaupt welche vorhanden sind). Beginne mit dem ersten Baum, den du geschrieben hast:

Nun können du dir deine neues Commit-Objekt mit git cat-file ansehen:

Das Format für ein Commit Objekt ist einfach: Es gibt den Baum der obersten Ebene für den Snapshot des Projekts zu diesem Zeitpunkt an; Das übergeordnete Objekt, falls vorhanden, (das oben beschriebene Commit Objekt hat keine übergeordneten Objekte); die Autoren-/Committer-Informationen (genutzt werden deine Konfigurationseinstellungen user.name und user.email sowie einen Zeitstempel); eine leere Zeile und dann die Commit-Nachricht.

Als Nächstes schreibe die beiden anderen Commit Objekte, die jeweils auf das Commit verweisen, welches direkt davor erfolgte:

Jedes der drei Commit-Objekte verweist auf einen der drei von dir erstellten Snapshot-Bäume. Seltsamerweise hast du jetzt einen echten Git-Verlauf, den du mit dem Befehl git log anzeigen kannst, wenn du ihn beim letzten Commit SHA-1 ausführst:

Wundervoll. Du hast gerade Basisbefehle der niedrigen Ebene ausgeführt, um einen Git-Verlauf zu erstellen, ohne einen der Standardbefehle zu verwenden. Dies ist im Wesentlichen das, was Git tut, wenn du die Befehle git add und git commit ausführst — es speichert Blobs für die geänderten Dateien, aktualisiert den Index, schreibt Bäume und schreibt Commit-Objekte, die auf Bäume der oberste Ebene verweisen und die Commits, die unmittelbar vor ihnen aufgetreten sind. Diese drei Haupt-Git-Objekte — der Blob, der Baum und das Commit – werden anfänglich als separate Dateien in deinem .git/objects Verzeichnis gespeichert. Hier sind jetzt alle Objekte im Beispielverzeichnis, kommentiert mit dem, was sie speichern:

Wenn du allen internen Zeigern folgst, erhältst du eine Objektgrafik in etwa wie folgt:

Wir haben bereits erwähnt, dass für jedes Objekt, das du in deine Git-Objektdatenbank übernimmst, ein Header gespeichert ist. Nehmen wir uns eine Minute Zeit, um zu sehen, wie Git seine Objekte speichert. Du wirst sehen, wie du ein Blob-Objekt — in diesem Fall die Zeichenfolge „what is up, doc?“ – interaktiv in der Ruby-Skriptsprache speicherst.

Du kannst den interaktiven Ruby-Modus mit dem Befehl irb starten:

Git erstellt zuerst einen Header, der mit der Identifizierung des Objekttyps beginnt — in diesem Fall ein Blob. Zu diesem ersten Teil des Headers fügt Git ein Leerzeichen hinzu, gefolgt von der Größe des Inhalts in Bytes, und fügt ein letztes Nullbyte hinzu:

Git verkettet den Header und den ursprünglichen Inhalt und berechnet dann die SHA-1-Prüfsumme dieses neuen Inhalts. Du kannst den SHA-1-Wert einer Zeichenfolge in Ruby berechnen, indem du die SHA1-Digest-Bibliothek mit dem Befehl require hinzufügst und dann Digest::SHA1.hexdigest() mit der Zeichenfolge aufrufst:

Vergleichen wir dies mit der Ausgabe von git hash-object. Hier verwenden wir echo -n, um zu verhindern, dass der Eingabe eine neue Zeile hinzugefügt wird.

Git komprimiert den neuen Inhalt mit zlib, was du in Ruby mit der zlib-Bibliothek tun kannst. Zuerst musst du die Bibliothek hinzufügen und dann Zlib::Deflate.deflate() auf den Inhalt ausführen:

Schließlich schreibst du deinen zlib-entpackten Inhalt auf ein Objekt auf der Festplatte. Du bestimmst den Pfad des Objekts, das du ausschreiben möchtest (die ersten beiden Zeichen des SHA-1-Werts sind der Name des Unterverzeichnisses und die letzten 38 Zeichen der Dateiname in diesem Verzeichnis). In Ruby kannst du die Funktion FileUtils.mkdir_p() verwenden, um das Unterverzeichnis zu erstellen, falls es nicht vorhanden ist. Öffne dann die Datei mit File.open() und schreibe den zuvor mit zlib komprimierten Inhalt mit einem write() -Aufruf auf das resultierende Dateihandle in die Datei:

Lass uns den Inhalt des Objekts mit git cat-file überprüfen:

Das war’s – Du hast ein gültiges Git-Blob-Objekt erstellt.

Alle Git-Objekte werden auf dieselbe Weise gespeichert, nur mit unterschiedlichen Typen. Anstelle des String-Blobs beginnt der Header mit commit oder tree. Auch wenn der Blob-Inhalt nahezu beliebig sein kann, sind Commit- und Tree-Inhalt sehr spezifisch formatiert.