Спробуйте спочатку наступні команди (за потреби повторно запустіть їх знову):
$ 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 = тепер $ 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 правильно виявляє всі зміни, що стосуються моїх файлів, і я можу розпочати свою роботу знову.