Сначала попробуйте выполнить следующие команды (при необходимости повторите попытку):
$ git fsck --full
$ git gc
$ git gc --prune=today
$ git fetch --all
$ git pull --rebase
И тогда у вас все еще есть проблемы, попробуйте:
удалите все поврежденные объекты, например
fatal: loose object 91c5...51e5 (stored in .git/objects/06/91c5...51e5) is corrupt
$ rm -v .git/objects/06/91c5...51e5
удалите все пустые объекты, например
error: object file .git/objects/06/91c5...51e5 is empty
$ find .git/objects/ -size 0 -exec rm -vf "{}" \;
проверьте сообщение о неработающей ссылке:
git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
Это сообщит вам, из какого файла был получен поврежденный объект!
для восстановления файла вам может очень повезти, и это может быть та версия, которую вы уже отметили в своем рабочем дереве:
git hash-object -w my-magic-file
снова, и если он выводит отсутствующий SHA1 (4b945 ..), все готово!
предполагая, что это была некоторая более старая версия, которая была сломана, самый простой способ сделать это - сделать:
git log --raw --all --full-history -- subdirectory/my-magic-file
и это покажет вам весь журнал для этого файла (пожалуйста, поймите, что дерево, которое у вас было, может не быть деревом верхнего уровня, поэтому вам нужно выяснить, в каком подкаталоге оно находилось самостоятельно), теперь вы можете воссоздать снова отсутствует объект с хеш-объектом.
чтобы получить список всех ссылок с отсутствующими коммитами, деревьями или каплями:
$ git for-each-ref --format='%(refname)' | while read ref; do git rev-list --objects $ref >/dev/null || echo "in $ref"; done
Возможно, невозможно удалить некоторые из этих ссылок с помощью обычных команд branch -d или tag -d, поскольку они умрут, если git заметит повреждение. Поэтому используйте команду сантехники git update-ref -d $ ref. Обратите внимание, что в случае локальных веток эта команда может оставить устаревшую конфигурацию ветки в .git / config. Его можно удалить вручную (ищите раздел [ветка «$ ref»]).
После того, как все ссылки будут чистыми, в журнале ссылок все еще могут быть неработающие коммиты. Вы можете очистить все рефлоги, используя git reflog expire --expire = now --all. Если вы не хотите терять все свои журналы, вы можете поискать в отдельных ссылках сломанные журналы:
$ (echo HEAD; git for-each-ref --format='%(refname)') | while read ref; do git rev-list -g --objects $ref >/dev/null || echo "in $ref"; done
(Обратите внимание на добавленную опцию -g для git rev-list.) Затем используйте git reflog expire --expire = now $ ref для каждого из них. Когда все сломанные ссылки и журналы исчезнут, запустите git fsck --full, чтобы проверить чистоту репозитория. Висячие предметы в порядке.
Ниже вы можете найти расширенное использование команд, которые потенциально могут привести к потере ваших данных в вашем репозитории git, если их не использовать с умом, поэтому сделайте резервную копию, прежде чем вы случайно нанесете дополнительный ущерб вашему git. Попробуйте на свой страх и риск, если знаете, что делаете.
Чтобы перетащить текущую ветку поверх восходящей ветки после выборки:
$ git pull --rebase
Вы также можете попробовать проверить новую ветку и удалить старую:
$ git checkout -b new_master origin/master
Чтобы найти поврежденный объект в git для удаления, попробуйте следующую команду:
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
Для OSX используйте sed -Eвместо sed -r.
Другая идея - распаковать все объекты из файлов пакета, чтобы восстановить все объекты внутри .git / objects, поэтому попробуйте выполнить следующие команды в своем репозитории:
$ 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
Если приведенное выше не помогает, вы можете попробовать rsync или скопировать объекты git из другого репо, например
$ 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
Чтобы исправить сломанную ветку при попытке оформления заказа, выполните следующие действия:
$ git checkout -f master
fatal: unable to read tree 5ace24d474a9535ddd5e6a6c6a1ef480aecf2625
Попробуйте удалить его и снова оформить заказ из восходящего потока:
$ git branch -D master
$ git checkout -b master github/master
В случае, если git переведет вас в отдельное состояние, проверьте masterи объедините с ним отдельную ветку.
Другая идея - рекурсивно переустановить существующий мастер:
$ git reset HEAD --hard
$ git rebase -s recursive -X theirs origin/master
Смотрите также:
.gitпапки, конечно) в только что клонированное репо ... а затем сделалgit statusв новом репо ... git правильно обнаруживает все затронутые изменения в моих файлах, и я могу снова начать свою работу.