Versuchen Sie zunächst die folgenden Befehle (führen Sie sie bei Bedarf erneut aus):
$ git fsck --full
$ git gc
$ git gc --prune=today
$ git fetch --all
$ git pull --rebase
Und dann haben Sie immer noch die Probleme, versuchen Sie können:
Entfernen Sie alle beschädigten Objekte, z
fatal: loose object 91c5...51e5 (stored in .git/objects/06/91c5...51e5) is corrupt
$ rm -v .git/objects/06/91c5...51e5
Entfernen Sie alle leeren Objekte, z
error: object file .git/objects/06/91c5...51e5 is empty
$ find .git/objects/ -size 0 -exec rm -vf "{}" \;
Überprüfen Sie eine Nachricht "defekter Link" durch:
git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
Hier erfahren Sie, aus welcher Datei der beschädigte Blob stammt!
Wenn Sie eine Datei wiederherstellen möchten, haben Sie möglicherweise großes Glück und es ist möglicherweise die Version, die Sie bereits in Ihrem Arbeitsbaum ausgecheckt haben:
git hash-object -w my-magic-file
wieder, und wenn es den fehlenden SHA1 (4b945 ..) ausgibt, sind Sie jetzt fertig!
Unter der Annahme, dass eine ältere Version defekt war, ist der einfachste Weg:
git log --raw --all --full-history -- subdirectory/my-magic-file
und das zeigt Ihnen das gesamte Protokoll für diese Datei (bitte beachten Sie, dass der Baum, den Sie hatten, möglicherweise nicht der Baum der obersten Ebene ist, sodass Sie selbst herausfinden müssen, in welchem Unterverzeichnis er sich befand), dann können Sie das jetzt neu erstellen fehlendes Objekt mit Hash-Objekt wieder.
um eine Liste aller Refs mit fehlenden Commits, Bäumen oder Blobs zu erhalten:
$ git for-each-ref --format='%(refname)' | while read ref; do git rev-list --objects $ref >/dev/null || echo "in $ref"; done
Es ist möglicherweise nicht möglich, einige dieser Verweise mit den regulären Befehlen branch -d oder tag -d zu entfernen, da sie sterben, wenn git die Beschädigung bemerkt. Verwenden Sie stattdessen den Installationsbefehl git update-ref -d $ ref. Beachten Sie, dass bei lokalen Verzweigungen dieser Befehl möglicherweise die veraltete Zweigkonfiguration in .git / config zurücklässt. Es kann manuell gelöscht werden (siehe Abschnitt [Zweig "$ ref"]).
Nachdem alle Refs sauber sind, kann es immer noch zu fehlerhaften Commits im Reflog kommen. Sie können alle Reflogs mit git reflog expire --expire = now --all löschen. Wenn Sie nicht alle Reflogs verlieren möchten, können Sie die einzelnen Refs nach defekten Reflogs durchsuchen:
$ (echo HEAD; git for-each-ref --format='%(refname)') | while read ref; do git rev-list -g --objects $ref >/dev/null || echo "in $ref"; done
(Beachten Sie die hinzugefügte Option -g zur git-Rev-Liste.) Verwenden Sie dann git reflog expire --expire = now $ ref für jede dieser Optionen. Wenn alle defekten Refs und Reflogs verschwunden sind, führen Sie git fsck --full aus, um zu überprüfen, ob das Repository sauber ist. Baumelnde Objekte sind in Ordnung.
Im Folgenden finden Sie eine erweiterte Verwendung von Befehlen, die möglicherweise zum Verlust Ihrer Daten in Ihrem Git-Repository führen können, wenn sie nicht mit Bedacht verwendet werden. Erstellen Sie daher ein Backup, bevor Sie versehentlich weitere Schäden an Ihrem Git anrichten. Probieren Sie es auf eigenes Risiko aus, wenn Sie wissen, was Sie tun.
So ziehen Sie den aktuellen Zweig nach dem Abrufen über den vorgelagerten Zweig:
$ git pull --rebase
Sie können auch versuchen, einen neuen Zweig auszuchecken und den alten zu löschen:
$ git checkout -b new_master origin/master
Versuchen Sie den folgenden Befehl, um das beschädigte Objekt in git zum Entfernen zu finden:
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
Verwenden Sie für OSX sed -Eanstelle von sed -r.
Eine andere Idee ist, alle Objekte aus Packdateien zu entpacken, um alle Objekte in .git / object neu zu generieren. Versuchen Sie daher, die folgenden Befehle in Ihrem Repository auszuführen:
$ 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
Wenn dies nicht hilft, können Sie versuchen, die Git-Objekte von einem anderen Repo zu synchronisieren oder zu kopieren, z
$ 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
So beheben Sie den defekten Zweig beim Auschecken wie folgt:
$ git checkout -f master
fatal: unable to read tree 5ace24d474a9535ddd5e6a6c6a1ef480aecf2625
Versuchen Sie es erneut zu entfernen und aus dem Upstream auszuchecken:
$ git branch -D master
$ git checkout -b master github/master
Falls Git Sie in einen getrennten Zustand versetzt, checken Sie den ab masterund führen Sie den getrennten Zweig darin zusammen.
Eine andere Idee ist, den vorhandenen Master rekursiv neu zu gründen:
$ git reset HEAD --hard
$ git rebase -s recursive -X theirs origin/master
Siehe auch:
.gitnatürlich ohne den Ordner) in das frisch geklonte Repo ... und danngit statusim neuen Repo ... git erkennt alle betroffenen Änderungen an meinen Dateien korrekt und ich kann meine Arbeit wieder aufnehmen.