Najpierw wypróbuj następujące polecenia (w razie potrzeby uruchom ponownie):
$ git fsck --full
$ git gc
$ git gc --prune=today
$ git fetch --all
$ git pull --rebase
A potem nadal masz problemy, spróbuj:
usuń wszystkie uszkodzone obiekty, np
fatal: loose object 91c5...51e5 (stored in .git/objects/06/91c5...51e5) is corrupt
$ rm -v .git/objects/06/91c5...51e5
usuń wszystkie puste przedmioty, np
error: object file .git/objects/06/91c5...51e5 is empty
$ find .git/objects/ -size 0 -exec rm -vf "{}" \;
sprawdź wiadomość „uszkodzony link”:
git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
Dzięki temu dowiesz się, z jakiego pliku pochodzi uszkodzony obiekt blob!
aby odzyskać plik, możesz mieć naprawdę szczęście i może to być wersja, którą już wypisałeś w swoim drzewie roboczym:
git hash-object -w my-magic-file
ponownie, a jeśli wyprowadza brakujący SHA1 (4b945 ..), wszystko gotowe!
zakładając, że zepsuta była jakaś starsza wersja, najłatwiej to zrobić:
git log --raw --all --full-history -- subdirectory/my-magic-file
a to pokaże ci cały dziennik dla tego pliku (pamiętaj, że drzewo, które miałeś, może nie być drzewem najwyższego poziomu, więc musisz samodzielnie dowiedzieć się, w którym podkatalogu się znajduje), a następnie możesz teraz odtworzyć ponownie brakuje obiektu z hash-object.
aby uzyskać listę wszystkich referencji z brakującymi zatwierdzeniami, drzewami lub blobami:
$ git for-each-ref --format='%(refname)' | while read ref; do git rev-list --objects $ref >/dev/null || echo "in $ref"; done
Może nie być możliwe usunięcie niektórych z tych referencji za pomocą zwykłych poleceń branch -d lub tag -d, ponieważ zginą, jeśli git zauważy uszkodzenie. Zamiast tego użyj polecenia hydraulicznego git update-ref -d $ ref. Zauważ, że w przypadku lokalnych gałęzi, to polecenie może pozostawić nieaktualną konfigurację gałęzi w .git / config. Można go usunąć ręcznie (poszukaj sekcji [branch "$ ref"]).
Po tym, jak wszyscy sędziowie są czyste, w reflogu nadal mogą być zepsute zatwierdzenia. Możesz wyczyścić wszystkie reflogi za pomocą git reflog expire --expire = now --all. Jeśli nie chcesz stracić wszystkich swoich reflogów, możesz przeszukać poszczególne referencje pod kątem uszkodzonych reflogów:
$ (echo HEAD; git for-each-ref --format='%(refname)') | while read ref; do git rev-list -g --objects $ref >/dev/null || echo "in $ref"; done
(Zwróć uwagę na dodaną opcję -g do git rev-list.) Następnie użyj git reflog expire --expire = now $ ref na każdym z nich. Kiedy wszystkie zepsute referencje i reflogs znikną, uruchom git fsck --full, aby sprawdzić, czy repozytorium jest czyste. Wiszące obiekty są w porządku.
Poniżej możesz znaleźć zaawansowane użycie poleceń, które potencjalnie mogą spowodować utratę danych w repozytorium git, jeśli nie są używane mądrze, więc zrób kopię zapasową, zanim przypadkowo wyrządzisz dalsze szkody swojemu gitowi. Spróbuj na własne ryzyko, jeśli wiesz, co robisz.
Aby przeciągnąć bieżącą gałąź na gałąź upstream po pobraniu:
$ git pull --rebase
Możesz także spróbować wyewidencjonować nowy oddział i usunąć stary:
$ git checkout -b new_master origin/master
Aby znaleźć uszkodzony obiekt w git do usunięcia, wypróbuj następujące polecenie:
while [ true ]; do f=`git fsck --full 2>&1|awk '{print $3}'|sed -r 's/(^..)(.*)/objects\/\1\/\2/'`; if [ ! -f "$f" ]; then break; fi; echo delete $f; rm -f "$f"; done
W przypadku OSX użyj sed -Ezamiast sed -r.
Innym pomysłem jest rozpakowanie wszystkich obiektów z plików paczek w celu ponownego wygenerowania wszystkich obiektów w .git / objects, więc spróbuj uruchomić następujące polecenia w swoim repozytorium:
$ cp -fr .git/objects/pack .git/objects/pack.bak
$ for i in .git/objects/pack.bak/*.pack; do git unpack-objects -r < $i; done
$ rm -frv .git/objects/pack.bak
Jeśli powyższe nie pomoże, możesz spróbować rsync lub skopiować obiekty git z innego repozytorium, np
$ rsync -varu git_server:/path/to/git/.git local_git_repo/
$ rsync -varu /local/path/to/other-working/git/.git local_git_repo/
$ cp -frv ../other_repo/.git/objects .git/objects
Aby naprawić uszkodzoną gałąź podczas próby płatności w następujący sposób:
$ git checkout -f master
fatal: unable to read tree 5ace24d474a9535ddd5e6a6c6a1ef480aecf2625
Spróbuj go usunąć i ponownie wyewidencjonuj z upstream:
$ git branch -D master
$ git checkout -b master github/master
W przypadku, gdy git wprowadzi cię w stan odłączony, wyewidencjonuj masteri połącz z nim odłączoną gałąź.
Innym pomysłem jest rekurencyjne przebudowanie istniejącego wzorca:
$ git reset HEAD --hard
$ git rebase -s recursive -X theirs origin/master
Zobacz też:
.gitfolderu oczywiście) do świeżo sklonowanego repozytorium ... a potemgit statusw nowym repozytorium ... git poprawnie wykrywa wszystkie zmiany w moich plikach i mogę ponownie rozpocząć pracę.