Objektspeicher, der mit diesem Repository verknüpft ist. Normalerweise ist ein Objektspeicher in sich geschlossen (d.h. alle Objekte, auf die von einem darin gefundenen Objekt verwiesen wird, sind auch darin enthalten), aber es gibt einige Möglichkeiten, dies zu verletzen.

Ein neu erzeugtes Objekt wird in seiner eigenen Datei gespeichert. Die Objekte werden in 256 Unterverzeichnissen verteilt, wobei die ersten beiden Zeichen des SHA1-Objektnamens verwendet werden, um die Anzahl der Verzeichniseinträge in objects selbst überschaubar zu halten. Objekte, die hier gefunden werden, werden oft als entpackte (oder lose) Objekte bezeichnet.

Packs (Dateien, die viele Objekte in komprimierter Form speichern, zusammen mit Indexdateien, die zufälligen Zugriff ermöglichen) befinden sich in diesem Verzeichnis.

Zusätzliche Informationen über den Objektspeicher werden in diesem Verzeichnis aufgezeichnet.

Diese Datei hilft langsamen Transportschichten dabei, herauszufinden, welche Packs in diesem Objektspeicher verfügbar sind. Jedes Mal, wenn ein Pack hinzugefügt oder entfernt wird, sollte git update-server-info ausgeführt werden, um diese Datei aktuell zu halten, wenn das Repository für langsame Transportschichten veröffentlicht wird. git repack tut dies standardmäßig.

Diese Datei zeichnet Pfade zu alternativen Objektspeichern auf, von denen dieser Objektspeicher Objekte leiht, ein Pfad pro Zeile. Beachten Sie, dass nicht nur native Git-Tools sie lokal verwenden, sondern auch der HTTP-Fetcher versucht, sie remote zu verwenden; dies funktioniert normalerweise, wenn Sie relative Pfade (relativ zur Objektbank, nicht zum Repository!) in Ihrer Alternates-Datei haben, aber es funktioniert nicht, wenn Sie absolute Pfade verwenden, es sei denn, der absolute Pfad im Dateisystem und die Web-URL sind dieselben. Siehe auch objects/info/http-alternates.

Diese Datei zeichnet URLs zu alternativen Objektspeichern auf, von denen dieses Repository Objekte leiht, die verwendet werden, wenn das Repository über HTTP abgerufen wird.

Referenzen werden in Unterverzeichnissen dieses Verzeichnisses gespeichert. Der Befehl git prune weiß, dass er Objekte erhalten soll, die von Refs in diesem Verzeichnis und seinen Unterverzeichnissen erreichbar sind. Dieses Verzeichnis wird ignoriert (außer refs/bisect, refs/rewritten und refs/worktree), wenn $GIT_COMMON_DIR gesetzt ist und stattdessen "$GIT_COMMON_DIR/refs" verwendet wird.

speichert die Spitzen-Commit-Objekte des Branches name

speichert jeden Objektnamen (nicht unbedingt ein Commit-Objekt oder ein Tag-Objekt, das auf ein Commit-Objekt zeigt).

speichert die Spitzen-Commit-Objekte von Branches, die von einem entfernten Repository kopiert wurden.

speichert die SHA-1 des Objekts, das <obj-sha1> ersetzt. Dies ist ähnlich wie info/grafts und wird intern von git-replace[1] verwendet und gepflegt. Solche Refs können zwischen Repositories ausgetauscht werden, während grafts dies nicht können.

speichert die gleichen Informationen wie refs/heads/, refs/tags/ und ähnliche auf effizientere Weise. Siehe git-pack-refs[1]. Diese Datei wird ignoriert, wenn $GIT_COMMON_DIR gesetzt ist und stattdessen "$GIT_COMMON_DIR/packed-refs" verwendet wird.

Ein Symref (siehe Glossar) auf den Namespace refs/heads/, der den aktuell aktiven Branch beschreibt. Er hat nicht viel Bedeutung, wenn das Repository nicht mit einem Arbeitsbaum verbunden ist (d.h. ein Bare Repository), aber ein gültiges Git-Repository muss die HEAD-Datei haben; einige Porcelains verwenden sie möglicherweise, um den designierten "Standard"-Branch des Repositories zu erraten (normalerweise master). Es ist legal, wenn der benannte Branch name nicht (noch) existiert. In einigen älteren Konfigurationen ist es ein symbolischer Link anstelle eines Symrefs, der auf den aktuellen Branch verweist.

Repository-spezifische Konfigurationsdatei. Diese Datei wird ignoriert, wenn $GIT_COMMON_DIR gesetzt ist und stattdessen "$GIT_COMMON_DIR/config" verwendet wird.

Arbeitsverzeichnis-spezifische Konfigurationsdatei für das Hauptarbeitsverzeichnis in einer Konfiguration mit mehreren Arbeitsverzeichnissen (siehe git-worktree[1]).

Eine veraltete Methode zum Speichern von Kurzbezeichnungen, die für die Angabe einer URL für git fetch, git pull und git push verwendet werden. Eine Datei kann als branches/<name> gespeichert werden und dann kann name für diese Befehle anstelle des repository Arguments angegeben werden. Siehe den Abschnitt REMOTES in git-fetch[1] für Details. Dieser Mechanismus ist veraltet und wird wahrscheinlich nicht in modernen Repositories gefunden. Dieses Verzeichnis wird ignoriert, wenn $GIT_COMMON_DIR gesetzt ist und stattdessen "$GIT_COMMON_DIR/branches" verwendet wird.

Hooks sind Anpassungsskripte, die von verschiedenen Git-Befehlen verwendet werden. Eine Handvoll Beispiel-Hooks werden installiert, wenn git init ausgeführt wird, aber alle sind standardmäßig deaktiviert. Um sie zu aktivieren, muss das .sample Suffix vom Dateinamen durch Umbenennen entfernt werden. Lesen Sie githooks[5] für weitere Details zu jedem Hook. Dieses Verzeichnis wird ignoriert, wenn $GIT_COMMON_DIR gesetzt ist und stattdessen "$GIT_COMMON_DIR/hooks" verwendet wird.

Wenn mehrere Arbeitsbäume verwendet werden, sind die meisten Dateien in $GIT_DIR pro Arbeitsbaum, mit wenigen bekannten Ausnahmen. Alle Dateien unter common werden jedoch zwischen allen Arbeitsbäumen geteilt.

Die aktuelle Indexdatei für das Repository. Sie wird in einem Bare Repository normalerweise nicht gefunden.

Der gemeinsame Indexteil, auf den von $GIT_DIR/index und anderen temporären Indexdateien verwiesen wird. Nur im Split-Index-Modus gültig.

Zusätzliche Informationen über das Repository werden in diesem Verzeichnis aufgezeichnet. Dieses Verzeichnis wird ignoriert, wenn $GIT_COMMON_DIR gesetzt ist und stattdessen "$GIT_COMMON_DIR/info" verwendet wird.

Diese Datei hilft langsamen Transportschichten dabei, herauszufinden, welche Refs in diesem Repository verfügbar sind. Wenn das Repository für langsame Transportschichten veröffentlicht wird, sollte diese Datei jedes Mal von git update-server-info neu generiert werden, wenn ein Tag oder Branch erstellt oder geändert wird. Dies geschieht normalerweise über den Hook hooks/update, der vom Befehl git-receive-pack ausgeführt wird, wenn Sie in das Repository git pushen.

Diese Datei zeichnet gefälschte Commit-Ahneninformationen auf, um vorzutäuschen, dass die Menge der Eltern eines Commits anders ist, als der Commit tatsächlich erstellt wurde. Eine Zeile pro Eintrag beschreibt einen Commit und seine gefälschten Eltern, indem ihre 40-stelligen hexadezimalen Objektnamen durch ein Leerzeichen getrennt und mit einem Zeilenumbruch abgeschlossen werden.

Diese Datei speichert nach Konvention der Porcelains die Liste der Ausschlussmuster. .gitignore ist die ignoriere Datei pro Verzeichnis. git status, git add, git rm und git clean schauen sie an, aber die Kern-Git-Befehle schauen sie nicht an. Siehe auch: gitignore[5].

Definiert, welche Attribute einem Pfad zugewiesen werden sollen, ähnlich wie bei pro Verzeichnis .gitattributes Dateien. Siehe auch: gitattributes[5].

Diese Datei speichert Sparse-Checkout-Muster. Siehe auch: git-read-tree[1].

Speichert Kurzbezeichnungen für URLs und Standard-Refnamen für die Interaktion mit entfernten Repositories über die Befehle git fetch, git pull und git push. Siehe den Abschnitt REMOTES in git-fetch[1] für Details. Dieser Mechanismus ist veraltet und wird wahrscheinlich nicht in modernen Repositories gefunden. Dieses Verzeichnis wird ignoriert, wenn $GIT_COMMON_DIR gesetzt ist und stattdessen "$GIT_COMMON_DIR/remotes" verwendet wird.

Protokolle von Änderungen an Refs werden in diesem Verzeichnis gespeichert. Siehe git-update-ref[1] für weitere Informationen. Dieses Verzeichnis wird ignoriert (außer logs/HEAD), wenn $GIT_COMMON_DIR gesetzt ist und stattdessen "$GIT_COMMON_DIR/logs" verwendet wird.

Protokolliert alle Änderungen, die an der Branch-Spitze namens name vorgenommen wurden.

Protokolliert alle Änderungen, die am Tag namens name vorgenommen wurden.

Dies ist ähnlich wie info/grafts, wird aber intern vom Shallow-Clone-Mechanismus verwendet und gepflegt. Siehe die Option --depth zu git-clone[1] und git-fetch[1]. Diese Datei wird ignoriert, wenn $GIT_COMMON_DIR gesetzt ist und stattdessen "$GIT_COMMON_DIR/shallow" verwendet wird.

Wenn diese Datei existiert, wird $GIT_COMMON_DIR (siehe git[1]) auf den in dieser Datei angegebenen Pfad gesetzt, wenn er nicht explizit gesetzt ist. Wenn der angegebene Pfad relativ ist, ist er relativ zu $GIT_DIR. Das Repository mit commondir ist ohne das von "commondir" referenzierte Repository unvollständig.

Enthält die Git-Repositories der Submodule.

Enthält administrative Daten für verknüpfte Arbeitsbäume. Jedes Unterverzeichnis enthält den arbeitsbaumbezogenen Teil eines verknüpften Arbeitsbaums. Dieses Verzeichnis wird ignoriert, wenn $GIT_COMMON_DIR gesetzt ist, in welchem Fall stattdessen "$GIT_COMMON_DIR/worktrees" verwendet wird.

Eine Textdatei, die den absoluten Pfad zurück zur .git-Datei enthält, die hierher verweist. Dies wird verwendet, um zu prüfen, ob das verknüpfte Repository manuell entfernt wurde und dieses Verzeichnis nicht mehr benötigt wird. Die mtime dieser Datei sollte jedes Mal aktualisiert werden, wenn das verknüpfte Repository aufgerufen wird.

Wenn diese Datei existiert, ist der verknüpfte Arbeitsbaum möglicherweise auf einem tragbaren Gerät und nicht verfügbar. Die Existenz dieser Datei verhindert, dass worktrees/<id> entweder automatisch oder manuell durch git worktree prune bereinigt wird. Die Datei kann einen String enthalten, der erklärt, warum das Repository gesperrt ist.

Arbeitsverzeichnis-spezifische Konfigurationsdatei.