Сначала попробуйте выполнить следующие команды (при необходимости повторите снова):
$ 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
Это скажет вам, из какого файла пришел поврежденный BLOB-объект!
для восстановления файла вам может повезти, и это может быть версия, которую вы уже проверили в своем рабочем дереве:
git hash-object -w my-magic-file
еще раз, и если он выдаст недостающий SHA1 (4b945 ..), то теперь все готово!
Если предположить, что это была старая версия, которая была сломана, самый простой способ сделать это:
git log --raw --all --full-history -- subdirectory/my-magic-file
и это покажет вам весь журнал для этого файла (обратите внимание, что дерево, которое у вас было, может не быть деревом верхнего уровня, поэтому вам нужно выяснить, в каком подкаталоге оно было самостоятельно), тогда вы можете Теперь снова создайте отсутствующий объект с помощью hash-object.
, чтобы получить список всех ссылок с отсутствующими коммитами, деревьями или каплями:
$ 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. Его можно удалить вручную (см. Раздел [branch "$ ref"]).
После того, как все ссылки очищены, в журнале все еще могут быть нарушенные коммиты. Вы можете очистить все reflogs, используя git reflog expire --expire = now --all. Если вы не хотите потерять все свои reflogs, вы можете найти отдельные refs для сломанных reflogs:
$ (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
Смотри также: