git ready

Was in deinem .git Verzeichnis ist

UPDATE: Ich habe ein paar hilfreiche Kommentare mit Korrekturen für einige Dateien und was sie tun erhalten. Danke für’s Weitergeben.

Einige der Dinge, die ich an Git am meisten mag, ist die Tatsache, dass Git alle seine Informationen an einem Ort aufbewahrt: Das .git Verzeichnis an der Wurzel des Projektverzeichnisses. Wenn du es noch nicht durchgewühlt hast, brauchst du dich darüber nicht ärgern! Darin gibt es ein paar nette Sahnehäubchen. Wir schauen uns die wichtigen Dateien und Verzeichnisse an und versuchen ein besseres Verständnis darüber zu bekommen, was unter der Haube vor sich geht.

Die grundlegende Struktur sieht wie folgt aus:

.
|-- COMMIT_EDITMSG
|-- FETCH_HEAD
|-- HEAD
|-- ORIG_HEAD
|-- branches
|-- config
|-- description
|-- hooks
|   |-- applypatch-msg
|   |-- commit-msg
|   |-- post-commit
|   |-- post-receive
|   |-- post-update
|   |-- pre-applypatch
|   |-- pre-commit
|   |-- pre-rebase
|   |-- prepare-commit-msg
|   `-- update
|-- index
|-- info
|   `-- exclude
|-- logs
|   |-- HEAD
|   `-- refs
|-- objects
`-- refs
    |-- heads
    |-- remotes
    |-- stash
    `-- tags

Wir gehen über ein paar normale Dateien, die sich im Hauptverzeichnis befinden:

• COMMIT_EDITMSG: Das ist die letzte Commit-Nachricht. Sie wird von Git überhaupt nicht verwendet, befindet sich aber hier aus Gründen der Referenz für dich.
• config: Enthält die Einstellungen für dieses Repository. Spezifische Konfigurationsvariablen können hier untergebracht werden (und sogar Aliase). Diese Datei wird vor allem dazu genutzt, den Ort entfernter Branches zu hinterlegen und ein paar Kerneinstellungen zu speichern, z.B. ob das Repository blank ist oder nicht.
• description: Wenn gitweb verwendet oder git instaweb gestartet werden, wird diese Beschreibung bei der Ansicht des Repositorys oder in der Listenansicht aller Repositories angezeigt.
• FETCH_HEAD: Die SHA-Hashes der Branch- oder Remote-Heads, die während des letzten git fetch aktualisiert worden sind.
• HEAD: Die aktuelle Referenz auf die Revision, die betrachtet wird. In den meisten Fällen ist das wahrscheinlich refs/heads/master.
• index: Der Staging Bereich mit Metadaten wie Zeitstempel, Dateinamen und SHA-Hashes von Dateien, die bereits von Git aufgenommen wurden.
• packed-refs: Verpackt ruhende Referenzen. Das ist keine endgültige Liste von Referenzen im Repository (Das refs Verzeichnis hat die echten Referenzen!). Wirf einen Blick auf gitsters Kommentar, um mehr Informationen darüber zu lesen.
• ORIG_HEAD: Bei einem Merge ist das der SHA-Hash des Branches, in den gemerged wird.
• MERGE_HEAD: Bei einem Merge ist das der SHA-Hash des Branches, von dem gemerged wird.
• MERGE_MODE: Wird zum Kommunizieren von Beschränkung verwendet, die ursprünglich an git merge und weiter an git commit bei Merge-Konflikten übergeben wurden, und wo ein separater git commit zum Abschließen der Aktion notwendig ist. Momentan ist --no-ff die einzige auf diese Weise übergebene Beschränkung.
• MERGE_MSG: Zählt die Konflikte auf, die während des aktuellen Merges aufgetreten sind.
• RENAMED-REF: Ich versuche das hier immer noch zu erschließen. Nach einem einfachen Grep durch den Quellcode sieht es so aus, dass diese Datei mit Fehlern beim Speichern von Referenzen im Zusammenhang steht.

Es gibt auch eine ganze Reihe von Verzeichnissen:

• hooks: Ein Verzeichnis, das schnell ein guter Freund werden wird. Es beinhaltet Scripte, die zu bestimmten Zeitpunkten bei der Arbeit mit Git ausgeführt werden, z.B. nach einem Commit oder vor einem Rebase. Eine ganze Artikelserie zu diesen Hooks ist geplant.
• info: Relativ uninteressant bis auf die Datei exclude, die sich darin befindet. Wir haben sie bereits bei Ignorieren von Dateien gesehen. Aber als Erinnerung, man kann diese Datei zum Ignorieren von Dateien im Projekt verwenden. Aber Vorsicht, sie wird nicht wie .gitignore versioniert.
• logs: Beinhaltet die Historie der unterschiedlichen Branches. Wird offensichtlich am meisten mit dem reflog-Befehl verwendet.
• objects: Gits internes Warenlager von Binärobjekten, die alle mit SHA-Hashes indiziert sind.
• rebase-apply: Die Werkbank für Rebase und für git am. Wenn du mutig bist, kannst du in die patch Datei eintauchen, wenn ein Patch nicht sauber angewendet wird.
• refs: Die Master-Kopie aller Referenzen, die in deinem Repository liegen, seien es Stashes, Tags, remote-tracking Branches oder lokale Branches.

Nur ein Wort der Weisheit, wenn es um das Wildern im Innenleben von Git geht: Stell sicher, dass du weißt, was du tust. Falls nicht, mache vorher ein Backup. Mit den Konfigurationsdateien und den Hooks herumhantieren ist recht einfach. Aber ich würde nicht im Datenspeicher herumwühlen, wenn ich nicht muss.

Es gibt noch mehr über das Innenleben von Git zu sagen, dass wir bisher noch nicht abgedeckt haben. Eine der besten Anleitungen ist das Git Community Book, und natürlich kannst du dir den Quellcode selbst herunterladen und einen Blick hinein werfen. Wenn du noch mehr Informationen über das Innenleben des .git Verzeichnisses hast, lass es uns in den Kommentaren wissen.