gittutorial-2 - Eine Einführung in Git: Teil Zwei

Sie sollten gittutorial[7] durcharbeiten, bevor Sie dieses Tutorial lesen.

Das Ziel dieses Tutorials ist es, zwei grundlegende Bestandteile der Git-Architektur vorzustellen – die Objektdatenbank und die Indexdatei – und dem Leser alles Notwendige an die Hand zu geben, um den Rest der Git-Dokumentation zu verstehen.

Lassen Sie uns ein neues Projekt starten und eine kleine Historie erstellen

Was sind die 7 Hex-Ziffern, mit denen Git auf den Commit geantwortet hat?

Wir haben in Teil Eins des Tutorials gesehen, dass Commits Namen wie diesen haben. Es stellt sich heraus, dass jedes Objekt in der Git-Historie unter einem 40-stelligen Hex-Namen gespeichert wird. Dieser Name ist der SHA-1-Hash des Inhalts des Objekts; unter anderem stellt dies sicher, dass Git niemals dieselben Daten doppelt speichert (da identische Daten einen identischen SHA-1-Namen erhalten) und dass der Inhalt eines Git-Objekts niemals geändert wird (da dies den Namen des Objekts ebenfalls ändern würde). Die 7 Zeichen langen Hex-Strings hier sind einfach die Abkürzung solcher 40 Zeichen langen Strings. Abkürzungen können überall dort verwendet werden, wo die 40 Zeichen langen Strings verwendet werden können, solange sie eindeutig sind.

Es ist zu erwarten, dass der Inhalt des Commit-Objekts, das Sie beim Befolgen des obigen Beispiels erstellt haben, einen anderen SHA-1-Hash generiert als der oben gezeigte, da das Commit-Objekt den Zeitpunkt seiner Erstellung und den Namen der Person, die den Commit durchführt, aufzeichnet.

Wir können Git mit dem Befehl cat-file nach diesem speziellen Objekt fragen. Kopieren Sie nicht die 40 Hex-Ziffern aus diesem Beispiel, sondern verwenden Sie die aus Ihrer eigenen Version. Beachten Sie, dass Sie sie auf nur wenige Zeichen kürzen können, um sich das Tippen aller 40 Hex-Ziffern zu ersparen

Ein Baum kann sich auf ein oder mehrere "Blob"-Objekte beziehen, die jeweils einer Datei entsprechen. Darüber hinaus kann ein Baum auch auf andere Baum-Objekte verweisen und so eine Verzeichnisstruktur erstellen. Sie können den Inhalt eines jeden Baumes mit ls-tree untersuchen (denken Sie daran, dass ein ausreichend langer Anfangsteil des SHA-1 ebenfalls funktioniert)

Somit sehen wir, dass dieser Baum eine Datei enthält. Der SHA-1-Hash ist ein Verweis auf die Daten dieser Datei

Ein "Blob" ist nur Dateidaten, die wir auch mit cat-file untersuchen können

Beachten Sie, dass dies die alten Dateidaten sind; das Objekt, das Git in seiner Antwort auf den ersten Baum benannt hat, war also ein Baum mit einem Schnappschuss des Verzeichniszustands, der durch den ersten Commit aufgezeichnet wurde.

Alle diese Objekte werden unter ihren SHA-1-Namen im Git-Verzeichnis gespeichert

und der Inhalt dieser Dateien ist nur die komprimierten Daten plus ein Header, der ihre Länge und ihren Typ angibt. Der Typ ist entweder ein Blob, ein Baum, ein Commit oder ein Tag.

Der einfachste zu findende Commit ist der HEAD-Commit, den wir über .git/HEAD finden können

Wie Sie sehen können, teilt uns dies mit, auf welchem Zweig wir uns gerade befinden, und dies geschieht durch die Benennung einer Datei im .git-Verzeichnis, die selbst einen SHA-1-Namen enthält, der sich auf ein Commit-Objekt bezieht, das wir mit cat-file untersuchen können

Das "tree"-Objekt hier verweist auf den neuen Zustand des Baumes

und das "parent"-Objekt verweist auf den vorherigen Commit

Das Baumobjekt ist der Baum, den wir zuerst untersucht haben, und dieser Commit ist ungewöhnlich, da er keine Eltern hat.

Die meisten Commits haben nur einen Elternteil, aber es ist auch üblich, dass ein Commit mehrere Elternteile hat. In diesem Fall repräsentiert der Commit einen Merge, wobei die Elternreferenzen auf die Köpfe der zusammengeführten Branches zeigen.

Neben Blobs, Bäumen und Commits ist der einzige verbleibende Objekttyp ein "Tag", den wir hier nicht besprechen werden; siehe git-tag[1] für Details.

Somit wissen wir nun, wie Git die Objektdatenbank zur Darstellung der Historie eines Projekts verwendet

Beachten Sie übrigens, dass viele Befehle einen Baum als Argument entgegennehmen. Aber wie wir oben sehen können, kann ein Baum auf verschiedene Arten referenziert werden – über den SHA-1-Namen dieses Baumes, über den Namen eines Commits, der auf den Baum verweist, über den Namen eines Branches, dessen Kopf auf diesen Baum verweist, usw. – und die meisten solchen Befehle können jede dieser Namen akzeptieren.

In Befehlssynopsen wird das Wort "tree-ish" manchmal verwendet, um ein solches Argument zu bezeichnen.

Das Hauptwerkzeug, das wir zum Erstellen von Commits verwendet haben, ist git-commit -a, das einen Commit erstellt, der alle Änderungen in Ihrem Arbeitsverzeichnis enthält. Aber was ist, wenn Sie nur Änderungen an bestimmten Dateien committen möchten? Oder nur bestimmte Änderungen an bestimmten Dateien?

Wenn wir uns ansehen, wie Commits im Hintergrund erstellt werden, werden wir sehen, dass es flexiblere Wege gibt, Commits zu erstellen.

Setzen wir unser Testprojekt fort, und modifizieren wir file.txt erneut

aber diesmal, anstatt sofort den Commit zu machen, machen wir einen Zwischenschritt und bitten um Diffs, um den Überblick zu behalten, was passiert

Der letzte Diff ist leer, aber es wurden keine neuen Commits gemacht, und der HEAD enthält immer noch nicht die neue Zeile

Also vergleicht *git diff* etwas anderes als den HEAD. Das, womit es vergleicht, ist tatsächlich die Indexdatei, die in .git/index im Binärformat gespeichert ist, deren Inhalt wir aber mit ls-files untersuchen können

Was unser *git add* also getan hat, war, einen neuen Blob zu speichern und dann eine Referenz darauf in die Indexdatei zu legen. Wenn wir die Datei erneut modifizieren, werden wir sehen, dass die neuen Modifikationen in der *git diff*-Ausgabe reflektiert werden

Mit den richtigen Argumenten kann *git diff* uns auch den Unterschied zwischen dem Arbeitsverzeichnis und dem letzten Commit oder zwischen dem Index und dem letzten Commit anzeigen

Zu jedem Zeitpunkt können wir einen neuen Commit mit *git commit* (ohne die Option "-a") erstellen und verifizieren, dass der committete Zustand nur die im Index gespeicherten Änderungen enthält, nicht die zusätzliche Änderung, die sich noch nur in unserem Arbeitsverzeichnis befindet

Standardmäßig verwendet *git commit* den Index zur Erstellung des Commits, nicht das Arbeitsverzeichnis; die Option "-a" zu commit weist es an, den Index zuerst mit allen Änderungen im Arbeitsverzeichnis zu aktualisieren.

Schließlich lohnt es sich, die Auswirkung von *git add* auf die Indexdatei zu betrachten

Die Auswirkung von *git add* war, einen Eintrag zur Indexdatei hinzuzufügen

Und, wie Sie mit cat-file sehen können, verweist dieser neue Eintrag auf den aktuellen Inhalt der Datei

Der Befehl "status" ist eine nützliche Möglichkeit, eine schnelle Zusammenfassung der Situation zu erhalten

Da der aktuelle Zustand von closing.txt im Index zwischengespeichert ist, wird er als "Changes to be committed" aufgeführt. Da file.txt Änderungen im Arbeitsverzeichnis hat, die sich nicht im Index widerspiegeln, wird es als "changed but not updated" markiert. Zu diesem Zeitpunkt würde die Ausführung von "git commit" einen Commit erstellen, der closing.txt (mit seinem neuen Inhalt) hinzufügt, aber file.txt nicht modifiziert.

Beachten Sie auch, dass ein reines git diff die Änderungen an file.txt anzeigt, aber nicht die Hinzufügung von closing.txt, da die Version von closing.txt in der Indexdatei mit der im Arbeitsverzeichnis identisch ist.

Neben der Tatsache, dass die Indexdatei als Staging-Bereich für neue Commits dient, wird sie auch beim Auschecken eines Branches aus der Objektdatenbank gefüllt und verwendet, um die an einem Merge-Vorgang beteiligten Bäume zu speichern. Siehe gitcore-tutorial[7] und die entsprechenden Manpages für Details.

An diesem Punkt sollten Sie alles wissen, was notwendig ist, um die Manpages für jeden der Git-Befehle zu lesen; ein guter Ausgangspunkt wären die Befehle, die in giteveryday[7] erwähnt werden. Sie sollten in gitglossary[7] unbekannte Fachbegriffe finden können.

Das Git User's Manual bietet eine umfassendere Einführung in Git.

gitcvs-migration[7] erklärt, wie man ein CVS-Repository in Git importiert und zeigt, wie man Git auf CVS-ähnliche Weise verwendet.

Einige interessante Beispiele für die Git-Nutzung finden Sie in den howtos.

Für Git-Entwickler geht gitcore-tutorial[7] detailliert auf die Mechanismen auf niedrigerer Ebene von Git ein, die beispielsweise bei der Erstellung eines neuen Commits eine Rolle spielen.

gittutorial[7], gitcvs-migration[7], gitcore-tutorial[7], gitglossary[7], git-help[1], giteveryday[7], The Git User’s Manual

Teil der git[1] Suite