Übersicht

git fsck [--full] [--unreachable] [--dangling] [--lost-found]

Beschreibung

Der git fsck-Befehl validiert die Integrität der Objektdatenbank: Jeder Commit, Tree, Blob und Tag wird auf korrekten Hash, gültiges Format und intakte Referenzen geprüft. Er identifiziert dangling Objekte (keine Ref zeigt auf sie, aber sie sind nicht aus einem Reflog unerreichbar) und unerreichbare Objekte (wirklich verwaist).

Das ist das bevorzugte Werkzeug zur Diagnose von Repository-Korruption (oft nach einem Festplatten-Ausfall oder einer unterbrochenen Operation) und zum Finden "verlorener" Commits in der dangling-Kategorie, die wiederherstellbar sein könnten.

Im täglichen Einsatz integriert sich git fsck eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git fsck --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.

Zu verstehen, wie git fsck mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git fsck hilft, alle drei zu vermeiden.

Häufige Optionen

Option	Beschreibung
--full	Prüft jedes Objekt, einschließlich erreichbarer.
--unreachable	Meldet unerreichbare Objekte.
--dangling	Meldet dangling Objekte (Standard).
--no-dangling	Unterdrückt dangling-Auflistung.
--lost-found	Schreibt dangling Objekte nach .git/lost-found/.
--connectivity-only	Überspringt Blob-Inhalts-Verifikation.
--strict	Meldet zusätzliche Warnungen.

Beispiele

git fsck --full
    # Umfassende Prüfung

    git fsck --lost-found
    # Materialisiert dangling Commits/Blobs in wiederherstellbare Dateien

    git fsck --unreachable --no-reflogs
    # Wirklich verwaiste Objekte finden (Reflog-Schutz ignoriert)

    git fsck --connectivity-only
    # Schnellere Prüfung, die Inhalts-Hashing überspringt

Häufige Fehler

Auf "unreachable"-Warnungen zu reagieren, ohne den Reflog-Schutz zu berücksichtigen, kann wiederherstellbare Arbeit verlieren. fsck ist nur lesend; es löscht selbst nichts. Von fsck gefundene Fehler werden oft durch git gc oder durch erneutes Klonen einer frischen Kopie behoben.

Verwandte Befehle

git gc, git reflog, git verify-pack, git prune