git fsck

Sprawdza integralność i spójność obiektów w bazie repozytorium.

git fsck (od file system check) to wbudowany „lekarz” Gita. Sprawdza integralność i spójność obiektów w bazie repozytorium — przechodzi po commitach, drzewach (tree), blobach i tagach, weryfikuje ich sumy SHA-1 oraz to, czy wszystkie wzajemnie się odwołują bez urwanych połączeń. Używasz go, gdy podejrzewasz uszkodzenie repo (np. po awarii dysku, przerwanym git pull, dziwnych komunikatach o „loose object is corrupt”), albo gdy chcesz odzyskać commit, który zgubiłeś po nieostrożnym git reset --hard czy usunięciu gałęzi. Sama komenda jest tylko diagnostyczna — czyta, nie psuje.

Składnia i najważniejsze opcje

Podstawowa składnia: git fsck [opcje]

  • --full — rozszerza kontrolę na obiekty w plikach pack, a nie tylko na luźne obiekty (od nowszych wersji Gita i tak włączone domyślnie, ale warto podać świadomie).
  • --unreachable — wypisuje obiekty, które istnieją, ale nie są osiągalne z żadnej referencji (gałęzi, taga, HEAD). Tu często czają się zgubione commity.
  • --dangling — pokazuje obiekty „wiszące”, czyli istniejące, lecz do których nic bezpośrednio nie prowadzi (zachowanie domyślne); --no-dangling wycisza tę sekcję.
  • --lost-found — zapisuje wiszące obiekty do .git/lost-found/ (commity do commit/, resztę do other/), żeby dało się je wygodnie obejrzeć.
  • --no-reflogs — pomija reflogi przy liczeniu osiągalności, więc commity trzymane tylko przez reflog też zostaną uznane za nieosiągalne.
  • --connectivity-only — sprawdza wyłącznie powiązania między obiektami, pomijając kosztowne liczenie sum kontrolnych. Dużo szybsze na wielkich repo.
  • --strict — bardziej rygorystyczna walidacja (wyłapuje np. drobne odstępstwa od formatu obiektów).

Przykłady użycia

  • git fsck — szybki przegląd zdrowia repozytorium; jeśli nic nie wyświetli (poza ewentualnymi „dangling”), jest spokojnie.
  • git fsck --full — pełna kontrola łącznie z zawartością paczek pack; tego użyj przy podejrzeniu realnego uszkodzenia.
  • git fsck --unreachable --no-reflogs — wyszukuje commity osierocone po reset --hard lub skasowanej gałęzi, których nie trzyma już reflog.
  • git fsck --lost-found — wrzuca wiszące obiekty do .git/lost-found/, skąd możesz je odtworzyć przez git show i git branch ratunek .
  • git fsck --connectivity-only — błyskawiczny test spójności na dużym repo, gdy nie chcesz czekać na liczenie sum SHA-1.

Częste błędy i pułapki

Najczęstsze nieporozumienie: „dangling commit” to nie błąd. To normalny efekt amendów, rebase’ów i resetów — Git po prostu trzyma jeszcze stare obiekty do czasu odśmiecania. Panika jest niepotrzebna. Pamiętaj też, że git fsck niczego nie naprawia — wskazuje problem, ale to git gc sprząta nieosiągalne obiekty (i potrafi na zawsze usunąć to, co fsck właśnie pokazał, więc nie odpalaj git gc --prune=now, dopóki nie odzyskasz tego, co chciałeś). Na potężnych repozytoriach pełny --full bywa wolny — wtedy ratuje --connectivity-only. I uwaga na okno czasowe: zgubione commity żyją zwykle, dopóki nie minie domyślny okres wygaśnięcia reflogu (ok. 90 dni) albo nie wymusisz przedwczesnego prune.

Powiązane komendy: git gc, git reflog, git cat-file, git show, git prune.