Einführung

Jede Git-Operation bewegt Daten zwischen drei Bereichen: dem Working Tree (Ihre Dateien), dem Index (Entwurf des nächsten Commits) und dem Repository (committete Historie unter .git). Zu benennen, was wohin bewegt wird, ist das einzelne nützlichste mentale Modell.

Einführung

Ein Remote-Tracking-Branch ist eine lokale Ref, die einen Branch auf einem Remote spiegelt. Sie leben unter refs/remotes/<remote>/ und werden von git fetch aktualisiert (und Operationen, die fetch implizieren, wie git pull und git clone). Sie committen nicht direkt auf sie.

Woher sie kommen

Die Standard-Refspec für origin lautet:

Einführung

Normalerweise zeigt HEAD auf eine Branch-Ref, die wiederum auf einen Commit zeigt. In Detached HEAD zeigt HEAD direkt auf einen Commit. Detached HEAD ist nicht kaputt; es ist ein bewusster Modus, der zum Inspizieren der Historie nützlich und zum gedankenlosen Committen gefährlich ist.

Einführung

Das Reflog zeichnet jede Änderung an HEAD und an jeder Branch-Spitze auf Ihrer lokalen Maschine auf. Es ist lokal, pro Klon, und wird nicht gepusht. Nahezu jeder "verlorene" Commit kann darüber gerettet werden.

Einführung

Git hat zwei grundlegend verschiedene Merge-Ergebnisse: Fast-Forward, bei dem die Spitze eines Branches einfach verschoben wird, und Three-Way, bei dem ein neuer Commit mit zwei Eltern erstellt wird. Die Wahl hängt davon ab, ob die Branches divergiert sind.

Fast-Forward

Wenn die Spitze von main ein Vorfahre von feature ist, ist kein echter Merge nötig. Git rückt einfach main vor:

Einführung

In Git ist ein Branch nur eine bewegliche Referenz auf einen Commit. Einen Branch zu erstellen bedeutet, eine 41-Byte-Datei zu erstellen. Verglichen mit zentralisierten Systemen, in denen Branches vollständige Verzeichniskopien sind, macht Gits Modell Branching günstig genug, um es leichtfertig zu nutzen.

Einführung

Der Index ist eine Binärdatei unter .git/index, die ein Tree-Objekt spiegelt: eine sortierte Liste von Pfaden mit Modus, Hash und Stat-Informationen. Er ist die Staging Area für den nächsten Commit und ein Cache, der es Git erlaubt, das erneute Hashen unveränderter Dateien zu überspringen.

Einführung

Objekte sind unveränderlich und durch Hash benannt. Referenzen sind die veränderlichen, menschenlesbaren Namen, die auf sie zeigen. Jeder Branch, Tag, Remote-Tracking-Branch und HEAD ist eine Ref.

Wo Refs leben

Refs sind Dateien (oder Einträge in der packed-refs-Datei) unter .git/refs/:

Einführung

Git benennt jedes Objekt nach dem kryptografischen Hash seines Inhalts. Das ist inhaltsadressierte Speicherung: Der Name ist der Fingerabdruck des Inhalts. Der Standard-Hash ist SHA-1 (160 Bit, 40 Hex-Zeichen). SHA-256-Unterstützung existiert seit Git 2.29 experimentell.

Wie ein Hash berechnet wird

Git stellt dem Rohinhalt einen Header der Form <type> <size>\0 voran und hasht dann:

Einführung

Gits Repository ist im Kern ein inhaltsadressierter Objektspeicher. Es gibt genau vier Objekttypen: Blob, Tree, Commit und Tag. Jede Operation berührt sie letztlich. Diese vier Typen zu verstehen entmystifiziert das meiste an Git.

Blobs

Ein Blob speichert Dateiinhalte, mehr nicht. Kein Dateiname, keine Berechtigungen, keine Historie. Zwei Dateien mit identischem Inhalt teilen sich einen Blob, unabhängig davon, wo sie im Tree liegen.