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.

Du kannst auto gc folgendermaßen manuell ausführen:

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

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

Wenn du git gc ausführst, 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 du eine Referenz aktualisierst, 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 du jedoch keine Referenz im refs Verzeichnis finden kannst, befindet sich diese wahrscheinlich in deiner packed-refs Datei.

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

Es wird der Punkt auf deiner Git-Reise kommen, an dem du versehentlich einen oder mehrere Commits verlierst. Im Allgemeinen geschieht dies, weil du einen Branch mittels force Option löschst und es sich herausstellt, dass du den Branch doch noch benötigt hast. Oder aber es passiert, dass du einen Branch hart zurückgesetzt hast und noch benötigte Commits verworfen hast. Was kannst du tun, um deine Commits zurückzuerhalten?

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

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

Du hast die beiden obersten Commits verloren. Du hast jetzt keinen Branch, von dem aus diese Commits erreichbar ist. Du musst 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ättest du es auswendig gelernt, oder?

Oft ist der schnellste Weg die Nutzung eines Tools namens git reflog. Während du arbeitest, zeichnet Git lautlos im Hintergrund auf, was dein HEAD ist und worauf es zeigt. Jedes Mal, wenn du Branches commitest oder änderst, wird das Reflog aktualisiert. Das reflog wird auch durch den Befehl git update-ref aktualisiert. Dies ist ein weiterer Grund, warum du diesen Befehl verwenden solltest, anstatt nur den SHA-1-Wert in deine ref-Dateien zu schreiben, wie in Git Referenzen beschrieben. Du kannst jederzeit sehen, wo du warst, indem du git reflog ausführst:

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 du eine normale Logausgabe für dein Reflog erhältst.

Es sieht so aus, als ob du das unterste Commit verloren hast. Du kannst es also wiederherstellen, indem du bei diesem Commit einen neuen Branch erstellst. Beispielsweise kannst du einen Branch mit dem Namen recover-branch bei diesem Commit (ab1afef) starten:

Sehr gut - jetzt hast du einen Branch namens recover-branch, in dem sich früher dein master Branch befand, wodurch die ersten beiden Commits wieder erreichbar sind. Angenommen, dein Verlust war aus irgendeinem Grund nicht im Reflog - du kannst dies simulieren, indem du recover-branch entfernst und das Reflog löschst. Jetzt sind die ersten beiden Commits nicht mehr erreichbar:

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

In diesem Fall kannst du deinen fehlenden Commit nach dem String „Dangling Commit“ sehen. Du kannst es auf die gleiche Weise wiederherstellen, indem du einen Branch hinzufügst, 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 deines 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 du Subversion- oder Perforce-Repositorys nach Git konvertierst. Da du in diesen Systemen nicht den gesamten Verlauf herunterlädst, hat dieses Model des Hinzufügens nur wenige Konsequenzen. Wenn du einen Import von einem anderen System durchgeführt hast oder auf andere Weise feststellst, dass dein Repository viel größer ist, als es sein sollte, kannst du große Objekte folgendermaßen finden und entfernen.

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

Zur Veranschaulichung füge deinem Test-Repository eine große Datei hinzu und entferne sie beim nächsten Commit. Anschließend suchst du sie und entfernst sie dauerhaft aus dem Repository. Füge deiner Historie zunächst ein großes Objekt hinzu:

Hoppla - du wolltest deinem Projekt keinen riesigen Tarball hinzufügen. Besser wäre, es loszuwerden:

Wende nun gc auf deine Datenbank an und prüfe, wie viel Speicherplatz du verwendest:

Du kannst den Befehl count-objects ausführen, um schnell zu sehen, wie viel Speicherplatz du verwendest:

Der size-pack Eintrag gibt die Größe deiner Packdateien in Kilobyte an. Somit verwendest du fast 5 MB an Speicherplatz. Vor dem letzten Commit hast du einen Wert von ungefähr 2 KB belegt. Wenn du die Datei aus dem vorherigen Commit entfernst, wird sie offensichtlich nicht aus deinem Verlauf entfernt. Jedes Mal, wenn jemand dieses Repository klont, muss er 5 MB klonen, um dieses winzige Projekt zu erhalten, da du versehentlich eine große Datei hinzugefügt hast. Besser wir werden sie los.

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

Das große Objekt befindet sich unten: 5 MB. Um herauszufinden, um welche Datei es sich handelt, verwende den Befehl rev-list, den du schonmal in Ein bestimmtes Commit-Message-Format erzwingen verwendet hast. Wenn du --objects an rev-list übergibst, werden alle festgeschriebenen SHA-1s und auch die BLOB-SHA-1s mit den ihnen zugeordneten Dateipfaden aufgelistet. Du kannst dies verwenden, um den Namen deines Blobs zu finden:

Jetzt musst du diese Datei von allen Bäumen in deiner Historie entfernen. Du kannst leicht sehen, welche Commits diese Datei geändert haben:

Du musst alle Commits hinter 7b30847 neu schreiben, um diese Datei vollständig aus deinem Git-Verlauf zu entfernen. Verwende dazu filter-branch, den du in Den Verlauf umschreiben verwendet hast:

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

Anstatt eine bestimmte Datei mit etwas wie rm file zu entfernen, musst du sie mit git rm --cached entfernen - du musst 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. Du kannst die gleiche Aufgabe mit --tree-filter ausführen, wenn du möchtest. Die Option --ignore-unmatch für git rm weist an, dass keine Fehler auftreten, wenn das zu entfernende Muster nicht vorhanden ist. Schließlich forderst du filter-branch auf, deine Historie erst ab dem Commit 7b30847 neu zu schreiben, da du weißt, wo dieses Problem begann. Andernfalls wird es von vorne beginnen und unnötig länger dauern.

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

Mal sehen, wie viel Platz du gespart hast.

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