10.7 Git Interna - Wartung und Datenwiederherstellung

Gelegentlich führt Git automatisch einen Befehl namens „auto gc“ aus. Meistens macht dieser Befehl gar nichts. Wenn sich jedoch zu viele lose Objekte (Objekte, die nicht in einem Packfile enthalten sind) oder zu viele Packfiles gibt, startet Git einen vollständigen git gc Befehl. Das „gc“ steht für Garbage Collect und der Befehl führt eine Reihe von Aktionen aus: Er sammelt alle losen Objekte und legt sie in Packfiles ab. Er fasst Packfiles zu einem großen Packfile zusammen. Außerdem entfernt er Objekte, die nicht von einem Commit erreichbar und ein paar Monate alt sind.

Sie können auto gc folgendermaßen manuell ausführen:

Auch dies tut im Allgemeinen nichts. Sie müssen ungefähr 7.000 lose Objekte oder mehr als 50 Packfiles haben, damit Git einen echten gc-Befehl ausführt. Sie können diese Grenzwerte mit den Konfigurationseinstellungen gc.auto und gc.autopacklimit ändern.

Die andere Aktion, die gc durchführt, ist Ihre Referenzen in eine einzige Datei zu packen. Angenommen, Ihr Repository enthält die folgenden Branches und Tags:

Wenn Sie git gc ausführen, befinden sich diese Dateien nicht mehr im Verzeichnis refs. Git verschiebt sie aus Gründen der Effizienz in eine Datei mit dem Namen .git/packed-refs, die so aussieht:

Wenn Sie eine Referenz aktualisieren, bearbeitet Git diese Datei nicht, sondern schreibt eine neue Datei in refs/heads. Um das passende SHA-1 für eine angegebene Referenz zu erhalten, prüft Git diese Referenz im refs Verzeichnis und prüft dann die packed-refs Datei als Fallback. Wenn Sie jedoch keine Referenz im refs Verzeichnis finden können, befindet sich diese wahrscheinlich in Ihrer packed-refs Datei.

Beachten Sie die letzte Zeile der Datei, die mit einem ^ beginnt. Dies bedeutet, dass das darüberliegende Tag ein annotiertes Tag ist und dass diese Zeile das Commit ist, auf das das annotierte Tag verweist.

Es wird der Punkt auf Ihrer Git-Reise kommen, an dem Sie versehentlich einen oder mehrere Commits verlieren. Im Allgemeinen geschieht dies, weil Sie einen Branch mittels force Option löschen und es sich herausstellt, dass Sie den Branch doch noch benötigten. Oder aber es passiert, dass Sie einen Branch hart zurückgesetzt haben und noch benötigte Commits verworfen haben. Was können sie tun, um ihre Commits zurückzuerhalten?

In diesem Beispiel wird der master Branch in Ihrem Test-Repository auf einen älteren Commit zurückgesetzt und die verlorenen Commits wiederhergestellt. Lassen Sie uns zunächst überprüfen, wo sich Ihr Repository zu diesem Zeitpunkt befindet:

Verschieben Sie nun den 'master'-Branch zurück zum mittleren Commit:

Sie haben die beiden obersten Commits verloren. Sie haben jetzt keinen Branch, von dem aus diese Commits erreichbar sind. Sie müssen das letzte Commit-SHA-1 finden und anschließend einen Branch hinzufügen, der darauf verweist. Der Trick ist, das letzte Commit SHA-1 zu finden. Leider ist es nicht so, als hätten Sie es auswendig gelernt, oder?

Oft ist der schnellste Weg die Nutzung eines Tools namens git reflog. Während sie arbeiten, zeichnet Git lautlos im Hintergrund auf, was ihr HEAD ist und worauf es zeigt. Jedes Mal, wenn Sie Branches commiten oder ändern, wird das Reflog aktualisiert. Das reflog wird auch durch den Befehl git update-ref aktualisiert. Dies ist ein weiterer Grund, warum Sie diesen Befehl verwenden sollten, anstatt nur den SHA-1-Wert in Ihre ref-Dateien zu schreiben, wie in Git Referenzen beschrieben. Sie können jederzeit sehen, wo Sie waren, indem Sie git reflog ausführen:

Hier sehen wir die beiden Commits, die wir ausgecheckt haben, jedoch gibt es hier nicht viele Informationen. Um die gleichen Informationen auf eine viel nützlichere Weise anzuzeigen, können wir git log -g ausführen, wodurch Sie eine normale Logausgabe für Ihr Reflog erhalten.

Es sieht so aus, als ob Sie das unterste Commit verloren haben. Sie können es also wiederherstellen, indem Sie bei diesem Commit einen neuen Branch erstellen. Beispielsweise können Sie einen Branch mit dem Namen recover-branch bei diesem Commit (ab1afef) starten:

Sehr gut - jetzt haben Sie einen Branch namens recover-branch, in dem sich früher Ihr master Branch befand, wodurch die ersten beiden Commits wieder erreichbar sind. Angenommen, Ihr Verlust war aus irgendeinem Grund nicht im Reflog - Sie können dies simulieren, indem Sie recover-branch entfernen und das Reflog löschen. Jetzt sind die ersten beiden Commits nicht mehr erreichbar:

Da sich die Reflog-Daten im Verzeichnis .git/logs/ befinden, haben Sie praktisch kein Reflog. Wie können Sie dieses Commit zu diesem Zeitpunkt wiederherstellen? Eine Möglichkeit ist die Verwendung des Hilfsprogramms git fsck, mit dem Ihre Datenbank auf Integrität überprüft wird. Wenn Sie es mit der Option --full ausführen, werden alle Objekte angezeigt, auf die kein anderes Objekt zeigt:

In diesem Fall können Sie Ihr fehlendes Commit nach dem String „Dangling Commit“ sehen. Sie können es auf die gleiche Weise wiederherstellen, indem Sie einen Branch hinzufügen, der auf diesen SHA-1 verweist.

Es gibt viele großartige Dinge an Git. Eine Funktion, die jedoch Probleme verursachen kann, ist die Tatsache, dass ein Git-Klon den gesamten Verlauf des Projekts herunterlädt, einschließlich jeder Version jeder Datei. Dies ist in Ordnung, wenn das Ganze Quellcode ist. Git ist stark darin, diese Daten effizient zu komprimieren. Wenn jedoch zu einem beliebigen Zeitpunkt im Verlauf Ihres Projekts eine einzelne große Datei hinzugefügt wird, muss jeder Klon für alle Zeiten diese große Datei herunterladen, auch wenn sie beim nächsten Commit aus dem Projekt entfernt wurde. Weil sie von der Historie aus erreichbar ist, wird sie immer da sein.

Dies kann ein großes Problem sein, wenn Sie Subversion- oder Perforce-Repositorys nach Git konvertieren. Da Sie in diesen Systemen nicht den gesamten Verlauf herunterladen, hat dieses Model des Hinzufügens nur wenige Konsequenzen. Wenn Sie einen Import von einem anderen System durchgeführt haben oder auf andere Weise feststellen, dass Ihr Repository viel größer ist, als es sein sollte, können Sie große Objekte folgendermaßen finden und entfernen.

Seien Sie gewarnt: Diese Technik wirkt sich zerstörerisch auf Ihren Commit-Verlauf aus. Es schreibt jedes Commitobjekt neu, seit dem frühesten Baum, den Sie ändern müssen, um einen Verweis auf eine große Datei zu entfernen. Wenn Sie dies unmittelbar nach einem Import tun, bevor jemand damit begonnen hat, sich auf das Commit zu stützen, ist alles in Ordnung. Andernfalls müssen Sie alle Mitwirkenden benachrichtigen, dass sie ihre Arbeit auf Ihre neuen Commits rebasen müssen.

Zur Veranschaulichung fügen Sie Ihrem Test-Repository eine große Datei hinzu, entfernen Sie sie beim nächsten Commit. Anschließend suchen Sie sie und entfernen sie dauerhaft aus dem Repository. Fügen Sie Ihrer Historie zunächst ein großes Objekt hinzu:

Hoppla - Sie wollten Ihrem Projekt keinen riesigen Tarball hinzufügen. Besser wäre, es loszuwerden:

Nun wenden sie gc auf Ihre Datenbank an und sehen sie, wie viel Speicherplatz Sie verwenden:

Sie können den Befehl count-objects ausführen, um schnell zu sehen, wie viel Speicherplatz Sie verwenden:

Der size-pack Eintrag gibt die Größe Ihrer Packdateien in Kilobyte an. Somit verwenden Sie fast 5 MB an Speicherplatz. Vor dem letzten Commit haben Sie einen Wert von ungefähr 2 KB belegt. Wenn Sie die Datei aus dem vorherigen Commit entfernen, würde sie offensichtlich nicht aus Ihrem Verlauf entfernt. Jedes Mal, wenn jemand dieses Repository klont, muss er 5 MB klonen, um dieses winzige Projekt zu erhalten, da Sie versehentlich eine große Datei hinzugefügt haben. Lass sie es uns loswerden.

Als erstes müssen wir es finden. In diesem Fall wissen Sie bereits, um welche Datei es sich handelt. Angenommen, Sie wissen es nicht. Wie würden Sie feststellen, welche Datei oder welche Dateien so viel Speicherplatz beanspruchen? Wenn Sie git gc ausführen, befinden sich alle Objekte in einer Packdatei. Sie können die großen Objekte identifizieren, indem Sie einen anderen Installationsbefehl namens git verify-pack ausführen und die Ausgabe nach dem dritte Feld sortieren, das die Dateigröße ist. Sie können es auch über den Befehl tail pipen, da Sie nur an den letzten, großen Dateien interessiert sind:

Das große Objekt befindet sich unten: 5 MB. Um herauszufinden, um welche Datei es sich handelt, verwenden Sie den Befehl rev-list, den Sie kurz in Ein bestimmtes Commit-Message-Format erzwingen verwendet haben. Wenn Sie --objects an rev-list übergeben, werden alle festgeschriebenen SHA-1s und auch die BLOB-SHA-1s mit den ihnen zugeordneten Dateipfaden aufgelistet. Sie können dies verwenden, um den Namen Ihres Blobs zu finden:

Jetzt müssen Sie diese Datei von allen Bäumen in Ihrer Historie entfernen. Sie können leicht sehen, welche Commits diese Datei geändert haben:

Sie müssen alle Commits hinter 7b30847 neu schreiben, um diese Datei vollständig aus Ihrem Git-Verlauf zu entfernen. Verwenden Sie dazu filter-branch, den Sie in Den Verlauf umschreiben verwendet haben:

Die Option --index-filter ähnelt der Option --tree-filter, die in Den Verlauf umschreiben verwendet wurde. Jedoch ändern sie jedes Mal Ihren Staging-Bereich oder Index anstatt daß sie einen Befehl zum Modifizieren von ausgecheckten Dateien auf ihrer Platte übergeben.

Anstatt eine bestimmte Datei mit etwas wie rm file zu entfernen, müssen Sie sie mit git rm --cached entfernen - Sie müssen sie aus dem Index entfernen, nicht von der Festplatte. Der Grund dafür ist die Geschwindigkeit - da Git nicht jede Revision auf der Festplatte auschecken muss, bevor der Filter ausgeführt wird, kann der Prozess sehr viel schneller sein. Sie können die gleiche Aufgabe mit --tree-filter ausführen, wenn Sie möchten. Die Option --ignore-unmatch für git rm weist an, dass keine Fehler auftreten, wenn das zu entfernende Muster nicht vorhanden ist. Schließlich fordern Sie filter-branch auf, Ihre Historie erst ab dem Commit 7b30847 neu zu schreiben, da Sie wissen, wo dieses Problem begann. Andernfalls wird es von vorne beginnen und unnötig länger dauern.

Ihr Verlauf enthält nun keinen Verweis mehr auf diese Datei. Ihr Reflog und eine neue Gruppe von Refs, die Git hinzugefügt hat, als Sie den filter-branch unter .git/refs/original ausgeführt haben, enthält jedoch weiterhin Verweise, sodass Sie sie entfernen und die Datenbank neu packen müssen. Sie müssen alles loswerden, das einen Zeiger auf diese alten Commits enthält, bevor Sie neu packen:

Mal sehen, wie viel Platz Sie gespart haben.

Die Größe des gepackten Repositorys beträgt nur noch 8 KB, was viel besser als 5 MB ist. Sie können anhand der Größe erkennen, dass sich das große Objekt noch in Ihren losen Objekten befindet, sodass es nicht verschwunden ist. Es wird jedoch nicht auf einen Push oder nachfolgenden Klon übertragen, was wichtig ist. Wenn Sie es wirklich wollten, können Sie das Objekt vollständig entfernen, indem Sie git prune mit der Option --expire ausführen:

` === Umgebungsvariablen

Git läuft immer in einer bash Shell und verwendet eine Reihe von Shell-Umgebungsvariablen, über die man steuern kann, wie es sich verhält. Gelegentlich ist es hilfreich zu wissen, welche diese sind und wie Sie Git dazu bringen können, sich so zu verhalten, wie Sie es möchten. Dies ist keine vollständige Liste aller Umgebungsvariablen auf die Git achtet, aber wir werden die nützlichsten behandeln.

Einige der generellen Eigenschaften von Git als Computerprogramm hängen von Umgebungsvariablen ab.

GIT_EXEC_PATH bestimmt, wo Git nach seinen Unterprogrammen sucht (wie git-commit, git-diff und andere). Sie können die aktuelle Einstellung überprüfen, indem Sie git --exec-path ausführen.

HOME wird normalerweise nicht als anpassbar angesehen (zu viele andere Dinge hängen davon ab), aber hier sucht Git nach der globalen Konfigurationsdatei. Wenn Sie eine wirklich portable Git-Installation mit globaler Konfiguration wünschen, können Sie HOME im portablen Git Shell-Profil überschreiben.

PREFIX ist ähnlich, jedoch für die systemweite Konfiguration. Git sucht nach dieser Datei unter $PREFIX/etc/gitconfig.

GIT_CONFIG_NOSYSTEM, falls gesetzt, deaktiviert die Verwendung der systemweiten Konfigurationsdatei. Dies ist nützlich, wenn Ihre Systemkonfiguration Ihre Befehle beeinträchtigt, Sie jedoch keinen Zugriff haben, um diese zu ändern oder zu entfernen.

GIT_PAGER steuert das Programm, mit dem mehrseitige Ausgaben in der Befehlszeile angezeigt werden. Ist dies nicht gesetzt, wird PAGER als Fallback verwendet.

GIT_EDITOR ist der Editor, den Git startet, wenn der Benutzer Text bearbeiten muss (z.B. eine Commit-Nachricht). Wenn nicht gesetzt, wird EDITOR verwendet.

Git verwendet mehrere Umgebungsvariablen, um die Verbindung zum aktuellen Repository herzustellen.

GIT_DIR ist der Speicherort des Ordners .git. Wenn dies nicht angegeben ist, geht Git nach oben durch den Verzeichnisbaum, bis es zu ~ oder / gelangt, und sucht bei jedem Schritt nach einem .git Verzeichnis.

GIT_CEILING_DIRECTORIES steuert das Verhalten bei der Suche nach einem .git Verzeichnis. Wenn Sie auf Verzeichnisse zugreifen, die nur langsam geladen werden können (z.B. auf einem Bandlaufwerk oder über eine langsame Netzwerkverbindung), möchten Sie möglicherweise, dass Git den Versuch vorzeitig abbricht, insbesondere wenn Git in der Kommandozeile aufgerufen wird.

GIT_WORK_TREE ist der Speicherort des Stammverzeichnisses eines Arbeitsverzeichnisses für ein non-bare Repository. Wenn --git-dir oder GIT_DIR angegeben ist, jedoch nicht --work-tree, GIT_WORK_TREE oder core.worktree, wird das aktuelle Arbeitsverzeichnis als oberste Ebene Ihres Arbeitsbaums betrachtet.

GIT_INDEX_FILE ist der Pfad zur Indexdatei (nur für non-bare Repositorys).

GIT_OBJECT_DIRECTORY kann verwendet werden, um den Speicherort des Verzeichnisses anzugeben, das sich normalerweise in .git/objects befindet.

GIT_ALTERNATE_OBJECT_DIRECTORIES ist eine durch Doppelpunkte getrennte Liste (also im Format /dir/one:/dir/two:… `), die Git mitteilt, wo nach Objekten gesucht werden soll, wenn sie sich nicht in GIT_OBJECT_DIRECTORY` befinden. Wenn Sie viele Projekte mit großen Dateien haben, die genau den gleichen Inhalt haben, können Sie damit vermeiden, dass zu viele Kopien davon gespeichert werden.

„Pathspec“ bezieht sich darauf, wie Sie Pfade in Git angeben, einschließlich der Verwendung von Platzhaltern. Diese werden in der Datei .gitignore aber auch in der Befehlszeile (git add *.c) verwendet.

GIT_GLOB_PATHSPECS und GIT_NOGLOB_PATHSPECS steuern das Standardverhalten von Platzhaltern in Pfadangaben. Wenn GIT_GLOB_PATHSPECS auf 1 gesetzt ist, werden Platzhalterzeichen als Platzhalter verwendet (dies ist die Standardeinstellung). Wenn GIT_NOGLOB_PATHSPECS auf 1 gesetzt ist, stimmen Platzhalterzeichen nur mit sich selbst überein. Dies bedeutet, dass .c nur mit einer Datei namens „ .c“ übereinstimmt und nicht mit einer Datei, deren Name mit .c endet. Sie können dies in Einzelfällen überschreiben, indem Sie die Pfadangabe mit :(glob) oder :(literal) beginnen, wie in :(glob)*.c.

GIT_LITERAL_PATHSPECS deaktiviert beide oben genannten Verhaltensweisen. Es können keine Platzhalterzeichen verwendet werden, und die Präfixe zum Überschreiben sind ebenfalls deaktiviert.

GIT_ICASE_PATHSPECS setzt alle Pfadangaben so, dass zwischen Groß- und Kleinschreibung nicht unterschieden wird.

Die endgültige Erstellung eines Git-Commit-Objekts erfolgt normalerweise über git-commit-tree, das diese Umgebungsvariablen als primäre Informationsquelle verwendet und nur dann auf Konfigurationswerte zurückgreift, wenn diese nicht vorhanden sind.

GIT_AUTHOR_NAME ist der für Menschen lesbare Name im Feld „author“.

GIT_AUTHOR_EMAIL ist die E-Mail-Adresse für das Feld „author“.

GIT_AUTHOR_DATE ist der Zeitstempel für das Feld „author“.

GIT_COMMITTER_NAME legt den für Menschen lesbaren Namen für das Feld „Committer“ fest.

GIT_COMMITTER_EMAIL ist die E-Mail-Adresse für das Feld „Committer“.

GIT_COMMITTER_DATE wird für den Zeitstempel im Feld „Committer“ verwendet.

EMAIL ist die Ersatz-E-Mail-Adresse für den Fall, dass der Konfigurationswert user.email nicht festgelegt ist. Wenn this nicht festgelegt ist, greift Git auf die Systembenutzer und Hostnamen zurück.

Git verwendet die Bibliothek curl, um Netzwerkoperationen über HTTP durchzuführen. GIT_CURL_VERBOSE weist Git an, alle von dieser Bibliothek generierten Nachrichten auszugeben. Dies ähnelt dem Ausführen von curl -v in der Befehlszeile.

GIT_SSL_NO_VERIFY weist Git an, SSL-Zertifikate nicht zu verifizieren. Dies kann manchmal erforderlich sein, wenn Sie ein selbstsigniertes Zertifikat verwenden, um Git-Repositorys über HTTPS bereitzustellen, oder wenn Sie gerade einen Git-Server einrichten, aber noch kein vollständiges Zertifikat installiert haben.

Wenn die Datenrate einer HTTP-Operation unter GIT_HTTP_LOW_SPEED_LIMIT Bytes pro Sekunde und länger als GIT_HTTP_LOW_SPEED_TIME Sekunden anhält, bricht Git diese Operation ab. Diese Werte überschreiben die Konfigurationswerte http.lowSpeedLimit und http.lowSpeedTime.

GIT_HTTP_USER_AGENT legt die User-Agent-Zeichenfolge fest, die von Git bei der Kommunikation über HTTP verwendet wird. Der Standardwert ist ein Wert wie git/2.0.0.

GIT_DIFF_OPTS ist eigentlich ein unzutreffender Name. Die einzigen gültigen Werte sind -u<n> oder --unified=<n>, wodurch die Anzahl der in einem git diff Befehl angezeigten Kontextzeilen konfiguriert wird.

GIT_EXTERNAL_DIFF überschreibt den Konfigurationswert diff.external. Wenn diese Variable gesetzt ist, ruft Git dieses Programm auf, wenn git diff aufgerufen wird.

GIT_DIFF_PATH_COUNTER und GIT_DIFF_PATH_TOTAL sind innerhalb des durch GIT_EXTERNAL_DIFF oder diff.external angegebenen Programms nützlich. Ersteres gibt an, welche Datei in einer Reihe von Dateien verglichen wird (beginnend mit 1), und Letzteres gibt die Gesamtzahl der Dateien im Stapel an.

GIT_MERGE_VERBOSITY steuert die Ausgabe für die rekursive Merge-Strategie. Folgende Werte sind zulässig:

Der Standardwert ist 2.

Möchten Sie wirklich wissen, was in Git abgeht? In Git ist eine umfangreiche Sammlung von Traces eingebettet, alles was Sie tun müssen, ist sie einzuschalten. Die möglichen Werte dieser Variablen lauten wie folgt:

GIT_TRACE steuert allgemeine Traces, die keiner bestimmten Kategorie zugeordnet werden können. Dies umfasst die Erweiterung von Aliasen und die Delegierung an andere Unterprogramme.

GIT_TRACE_PACK_ACCESS steuert das Tracing der Packfile-Zugriffe. Das erste Feld ist die Packdatei, auf die zugegriffen wird, das zweite Feld ist der Offset in dieser Datei:

GIT_TRACE_PACKET aktiviert die Paketverfolgung für Netzwerkoperationen.

GIT_TRACE_PERFORMANCE steuert die Protokollierung von Performancedaten. Die Ausgabe zeigt, wie lange jeder einzelne Aufruf von git dauert.

GIT_TRACE_SETUP zeigt Informationen darüber an, was Git über das Repository und die Umgebung, mit denen es interagiert, herausfindet.

GIT_SSH, falls angegeben, ist ein Programm, das anstelle von ssh aufgerufen wird, um eine Verbindung zu einem SSH-Host herzustellen. Es wird folgendermaßen aufgerufen: $GIT_SSH [username@]host [-p <port>] <befehl>. Beachten Sie, dass dies nicht der einfachste Weg ist, um zu konfigurieren, wie ssh aufgerufen wird. Es werden keine zusätzlichen Befehlszeilenparameter unterstützt, daher müssen Sie ein Wrapper-Skript schreiben und GIT_SSH so einstellen, dass es darauf verweist. Es ist wahrscheinlich einfacher, dafür einfach die Datei ~/.ssh/config zu verwenden.

GIT_ASKPASS dient zur Überschreibung des Konfigurationswertes core.askpass. Dies ist das Programm, das immer dann aufgerufen wird, wenn Git den Benutzer nach Anmeldeinformationen fragen muss, wobei eine Eingabeaufforderung als Befehlszeilenargument erwartet wird und die eine Antwort auf stdout zurückgeben soll. Weitere Informationen zu diesem Subsystem finden Sie unter Anmeldeinformationen speichern.

GIT_NAMESPACE steuert den Zugriff auf namenspaced refs und entspricht dem Flag --namespace. Dies ist vor allem auf der Serverseite nützlich, wo Sie möglicherweise mehrere Forks eines einzelnen Repositorys in einem Repository speichern möchten, wobei nur die Refs getrennt bleiben.

GIT_FLUSH kann verwendet werden, um Git zu zwingen, nicht gepuffertes I/O zu verwenden, wenn inkrementell in stdout geschrieben wird. Ein Wert von 1 bewirkt, dass Gits Puffer öfter geleert wird. Ein Wert von 0 bewirkt, dass alle Ausgaben gepuffert werden. Der Standardwert (falls diese Variable nicht festgelegt ist) ist die Auswahl eines geeigneten Pufferschemas abhängig von Aktivität und Ausgabemodus.

Mit GIT_REFLOG_ACTION können Sie den beschreibenden Text angeben, der in das Reflog geschrieben wird. Hier ein Beispiel: