Как исправить ошибку GIT: объектный файл пуст?

Когда я пытаюсь зафиксировать изменения, я получаю эту ошибку:

error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty
fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt

Есть идеи, как решить эту ошибку?

РЕДАКТИРОВАТЬ

Я пытался git fsckу меня есть:

error: object file .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71 is empty
fatal: loose object 03dfd60a4809a3ba7023cbf098eb322d08630b71 (stored in .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71) is corrupt

У меня была аналогичная проблема. В моем ноутбуке разрядился аккумулятор во время операции git. Бу.

У меня не было никаких резервных копий. (NB Ubuntu One не является решением для резервного копирования для git; он будет перезаписывать ваш нормальный репозиторий вашим поврежденным.)

Для мастеров мерзавцев, если это был плохой способ исправить это, пожалуйста, оставьте комментарий. Это, однако, сработало для меня ... по крайней мере, временно.

Шаг 1: Сделайте резервную копию .git (фактически я делаю это между каждым шагом, который что-то меняет, но с новым именем для копирования, например .git-old-1, .git-old-2 и т. Д.) :

cp -a .git .git-old

Шаг 2: Запустить git fsck --full

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty
fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt

Шаг 3: Удалить пустой файл. Я понял, какого черта; все равно пусто

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e 
rm: remove write-protected regular empty file `.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e'? y

Шаг 3: Запустите git fsckснова. Продолжить удаление пустых файлов. Вы также можете cdв .gitкаталог и запустить, find . -type f -empty -delete -printчтобы удалить все пустые файлы. В конце концов, git начал говорить мне, что он что-то делает с каталогами объектов:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: object file .git/objects/e0/cbccee33aea970f4887194047141f79a363636 is empty
fatal: loose object e0cbccee33aea970f4887194047141f79a363636 (stored in .git/objects/e0/cbccee33aea970f4887194047141f79a363636) is corrupt

Шаг 4: После удаления всех пустых файлов я в конечном итоге приступил к git fsckработе:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: HEAD: invalid sha1 pointer af9fc0c5939eee40f6be2ed66381d74ec2be895f
error: refs/heads/master does not point to a valid object!
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Шаг 5: попробуй git reflog. Сбой, потому что моя голова сломана.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reflog
fatal: bad object HEAD

Шаг 6: Google. Найди это . Вручную получите две последние строки reflog:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ tail -n 2 .git/logs/refs/heads/master
f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <nathanvan@gmail.com> 1347306977 -0400  commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <nathanvan@gmail.com> 1347358589 -0400  commit: fixed up to page 28

Шаг 7: Обратите внимание, что из шага 6 мы узнали, что HEAD в данный момент указывает на самый последний коммит. Итак, давайте попробуем просто взглянуть на родительский коммит:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git show 9f0abf890b113a287e10d56b66dbab66adc1662d
commit 9f0abf890b113a287e10d56b66dbab66adc1662d
Author: Nathan VanHoudnos <nathanvan@XXXXXX>
Date:   Mon Sep 10 15:56:17 2012 -0400

    up to p. 24, including correcting spelling of my name

diff --git a/tex/MCMC-in-IRT.tex b/tex/MCMC-in-IRT.tex
index 86e67a1..b860686 100644
--- a/tex/MCMC-in-IRT.tex
+++ b/tex/MCMC-in-IRT.tex

Это сработало!

Шаг 8: Теперь нам нужно указать HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d

Который не жаловался.

Шаг 9: Посмотрите, что говорит fsck:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Шаг 10. Недопустимый указатель sha1 в дереве кеша выглядел так, как будто он был из (теперь устаревшего) индексного файла ( источника ). Поэтому я убил его и сбросил репо.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/index
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reset
Unstaged changes after reset:
M   tex/MCMC-in-IRT.tex
M   tex/recipe-example/build-example-plots.R
M   tex/recipe-example/build-failure-plots.R

Шаг 11: Снова посмотрим на fsck ...

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a

В свисающие сгустки не являются ошибками . Я не имею отношения к master.u1conflict, и теперь, когда он работает, я не хочу больше его трогать!

Шаг 12: Догоняю с моими местными правками:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   tex/MCMC-in-IRT.tex
#   modified:   tex/recipe-example/build-example-plots.R
#   modified:   tex/recipe-example/build-failure-plots.R
#
< ... snip ... >
no changes added to commit (use "git add" and/or "git commit -a")


nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "recovering from the git fiasco"
[master 7922876] recovering from the git fiasco
 3 files changed, 12 insertions(+), 94 deletions(-)

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git add tex/sept2012_code/example-code-testing.R
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "adding in the example code"
[master 385c023] adding in the example code
 1 file changed, 331 insertions(+)
 create mode 100644 tex/sept2012_code/example-code-testing.R

Надеюсь, что это может пригодиться людям в будущем. Я рад, что это сработало.

Объектные файлы git повреждены (как указано в других ответах). Это может произойти во время поломок машины и т. Д.

У меня было то же самое. Прочитав остальные ответы здесь, я нашел самый быстрый способ исправить поврежденный репозиторий git с помощью следующих команд (выполнить в рабочем каталоге git, который содержит эту .gitпапку):

(Обязательно сделайте резервную копию вашей папки git-репозитория!)

find .git/objects/ -type f -empty | xargs rm
git fetch -p
git fsck --full

Сначала будут удалены все пустые объектные файлы, которые вызывают повреждение хранилища в целом, а затем извлечены недостающие объекты (а также последние изменения) из удаленного хранилища, а затем будет выполнена полная проверка хранилища объектов . Что, на данный момент, должно произойти без каких-либо ошибок (хотя могут быть некоторые предупреждения!)

PS. Этот ответ предполагает, что у вас есть удаленная копия вашего git-репозитория (например, на GitHub), а поврежденный репозиторий является локальным репозиторием, который привязан к удаленному репозиторию, который все еще находится в такте. Если это не так, не пытайтесь исправить это так, как я рекомендую.

Эта ошибка происходит со мной, когда я нажимаю коммит и мой компьютер зависает. Вот как я это исправлю.

Шаги, чтобы исправить

git status

показать пустой / поврежденный объектный файл

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

убери это

git status

Я получил fatal: bad object HEADсообщение

rm .git/index

Я удаляю indexдля сброса

git reset

Неустранимый: не удалось разобрать объект 'HEAD'.

git status
git pull

просто чтобы проверить, что происходит

tail -n 2 .git/logs/refs/heads/MY-CURRENT-BRANCH

печатает последние 2 строки tail -n 2ветки журнала, чтобы показать мои последние 2commit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

Я выбираю последний commit hash

git status

показывает все мои файлы, deletedпотому что я удалил .git/indexфайл

git reset

продолжить сброс

git status

проверить мое исправление

Примечание: шаги начинаются, когда я попал на этот вопрос и использовал ответы в качестве ссылки.

Я решил это, удалив различные пустые файлы, которые обнаружил git fsck, и затем запустил простое git pull.

Я разочарован тем, что теперь, когда даже файловые системы реализуют журналирование и другие «транзакционные» методы, чтобы сохранить здравый смысл, git может перейти в поврежденное состояние (и не сможет восстановиться сам по себе) из-за сбоя питания или нехватки места на устройстве.

У меня была та же самая проблема: после извлечения удаленного хранилища, когда я сделал состояние git, я получил: «ошибка: объектный файл (...) пуст» «фатальный: свободный объект (...) поврежден»

Я решил это так:

1. мерзавец
2. удаление файла git по ошибке (не уверен, что это необходимо)
3. git stash clear

Я не знаю точно, что произошло, но эти инструкции, казалось, сделали все чисто.

Потому что мне приходится регулярно перезагружать виртуальную машину, поэтому почему-то эта проблема случается со мной очень часто. После нескольких раз я понял, что не могу повторять процесс, описанный @ Nathan-Vanhoudnos, каждый раз, когда это происходит, хотя он всегда работает. Тогда я выяснил следующее более быстрое решение.

Шаг 1

Переместите весь репо в другую папку.

mv current_repo temp_repo

Шаг 2

Снова клонируйте репо из оригинала.

git clone source_to_current_repo.git

Шаг 3

Удалите все в новом репо, кроме папки .git .

Шаг 4

Перемещение Все , что от temp_repo к новому репо за исключением в .git папки.

Шаг 5

Удалите temp_repo , и все готово.

Я уверен, что через несколько раз вы сможете сделать это очень быстро.

1. mv приложение вашей папки, чтобы сделать резервную копию, т.е. mv app_folder app_folder_bk (это как git stash )
2. git clone your_repository
3. В заключение,. Откройте инструмент слияния (я использую meld diff viewer linux или Winmerge Windows) и скопируйте изменения справа ( app_folder_bk ) влево (new app_folder ) (это похоже на git stash apply ).

Это все. Может быть, это не самый лучший способ, но я думаю, что это так практично.

В моем случае эта ошибка произошла из-за того, что я набирал сообщение о коммите и мой блокнот выключился.

Я сделал эти шаги, чтобы исправить ошибку:

• git checkout -b backup-branch # Создать резервную ветку
• git reset --hard HEAD~4# Сброс на коммит, где все работает хорошо. В моем случае мне пришлось вернуть 4 коммита в голове, то есть до тех пор, пока моя голова не окажется в точке, до которой я набрал сообщение о коммите. Перед выполнением этого шага скопируйте хэш коммитов, которые вы сбросите, в моем случае я скопировал хэш 4 последних коммитов
• git cherry-pick <commit-hash> # Вишня выбирает сброшенные коммиты (в моем случае это 4 коммита, поэтому я проделал этот шаг 4 раза) из старой ветви в новую.
• git push origin backup-branch # Нажмите на новую ветку, чтобы убедиться, что все работает хорошо
• git branch -D your-branch # Удалить ветку локально ('your-branch' - ветка с проблемой)
• git push origin :your-branch # Удалить ветку с удаленного
• git branch -m backup-branch your-branch # Переименуйте резервную ветвь, чтобы получить имя ветки, в которой возникла проблема
• git push origin your-branch # Нажмите новую ветку
• git push origin :backup-branch # Удалить резервную ветку с удаленного

git stash
git checkout master
cd .git/ && find . -type f -empty -delete
git branch your-branch-name -D
git checkout -b your-branch-name
git stash pop

решить мою проблему

Вот действительно простой и быстрый способ решения этой проблемы, если у вас есть локальное репо со всеми необходимыми ветками и коммитами, и если вы в порядке с созданием нового репо (или удалением репо сервера и созданием нового) на своем месте)

1. Создайте новый пустой репо на сервере (или удалите старый репо и создайте новый вместо него)
2. Измените удаленный URL-адрес вашей локальной копии, чтобы он указывал на удаленный URL-адрес нового репо.
3. Переместите все филиалы из вашего локального репо на новый репо сервера.

Это сохраняет всю историю коммитов и веток, которые у вас были в вашем локальном репо.

Если у вас есть соавторы в репо, то я думаю, что во многих случаях все ваши соавторы должны также изменять удаленный URL-адрес своего локального репо и, при необходимости, выдвигать любые коммиты, которые у них есть, которых нет на сервере.

Это решение сработало для меня, когда я столкнулся с этой же проблемой. У меня был один сотрудник. После того, как я перенес свое локальное репо в новое удаленное репо, он просто изменил свое локальное репо, чтобы оно указывало на URL удаленного репо, и все работало нормально.

Я предполагаю, что у вас есть пульт со всеми соответствующими изменениями, уже внесенными в него. Я не заботился о локальных изменениях и просто хотел избежать удаления и повторного создания большого хранилища. Если у вас есть важные локальные изменения, вы можете быть осторожнее.

У меня была такая же проблема после того, как мой ноутбук сломался. Возможно, потому что это был большой репозиторий, у меня было довольно много поврежденных объектных файлов, которые появлялись только по одному при вызове git fsck --full, поэтому я написал небольшую однострочную оболочку для автоматического удаления одного из них:

$ sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`

• 2>&1 перенаправляет сообщение об ошибке на стандартный вывод, чтобы иметь возможность его grep
• Используемые опции grep:
  • -o возвращает только ту часть строки, которая действительно соответствует
  • -E позволяет расширенные регулярные выражения
  • -m 1 убедитесь, что возвращается только первое совпадение
  • [0-9a-f]{2} соответствует любому из символов от 0 до 9 и a и f, если два из них встречаются вместе
  • [0-9a-f]* соответствует любому количеству символов от 0 до 9, а a и f встречаются вместе

Он по-прежнему удаляет только один файл за раз, поэтому вы можете вызвать его в цикле, например:

$ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; done

Проблема в том, что он больше не выводит ничего полезного, поэтому вы не знаете, когда он закончится (через некоторое время он просто не должен делать ничего полезного)

Чтобы «исправить» это, я просто добавил вызов git fsck --fullпосле каждого раунда так: $ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; git fsck --full; done

Теперь он примерно в два раза быстрее, но выдает «состояние».

После этого я поэкспериментировал с предложениями в этой ветке и, наконец, дошел до того, что смог git stashи git stash dropмного испорченного материала.

первая проблема решена

После этого у меня все еще была следующая проблема: unable to resolve reference 'refs/remotes/origin/$branch': reference brokenкоторая могла быть решена $ rm \repo.git\refs\remotes\origin\$branch

$ git fetch

Я тогда сделал $ git gc --prune=now

$ git remote prune origin

для хорошей меры и

git reflog expire --stale-fix --all

избавиться от error: HEAD: invalid reflog entry $blubbбега git fsck --full.

Пойдем просто .. только в том случае, если вы загрузили исходный код в удаленный репозиторий git

1. Сделайте резервную копию вашего .git

2. проверь свой мерзавец

   git fsck --full
   

3. удалить пустой объектный файл (все)

   rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
   

4. проверьте свой мерзавец снова.

   git fsck --full
   

5. вытащить свой источник из удаленного Git

   git pull origin master
   

Я сталкиваюсь с этой проблемой много с виртуальными машинами.

Для меня работает следующее:

cd /path/to/your/project
rm -rf .git

Если вы хотите сэкономить некоторые загрузки - зайдите в свой файловый менеджер и удалите все файлы в папке, которые уже зафиксированы, и оставьте в ваших папках / vendor и / node_modules (я работаю с composer и npm).

затем просто создайте новый репо

git init

добавить свой пульт

git remote add origin ssh://git@github.com/YourUsername/repoName.git

и получить ветку / все это

git fetch origin somebranch

и проверить это

git checkout somebranch

тогда вы должны быть в точке до ошибки.

Надеюсь это поможет.

С уважением.

Я сталкиваюсь с той же проблемой, и я использую очень простой способ ее устранения. Я обнаружил, что эти пропавшие файлы существуют на компьютере моего товарища по команде.

Я скопировал эти файлы один за другим на git-сервер (всего 9 файлов), и это решило проблему.

Я и мои коллеги несколько раз сталкивались с этой же проблемой, и для ее решения мы просто делаем шаги, которые я опишу ниже. Это не самое элегантное решение, которое можно найти, но оно работает без потери данных.

1. Переименуйте текущий рабочий каталог. (old_project для этого примера).
2. Клонируйте репозиторий в новом каталоге, используя git clone.
3. В командной строке измените рабочий каталог на вновь созданный проект и переключитесь на ветку, над которой вы работали.
4. Скопируйте все файлы и каталоги old_project(кроме .gitкаталога) во вновь созданный каталог проекта.
5. Проверьте свое рабочее дерево (обратите внимание, что изменений намного больше, чем вы ожидаете), а затем зафиксируйте изменения.

Я надеюсь, что это помогает...

Вот способ решить проблему, если ваше публичное репо на github.com работает, но ваше локальное репо повреждено. Имейте в виду, что вы потеряете все коммиты, которые вы сделали в локальном репо.

Хорошо, так что у меня есть один репо локально, который дает мне это object empty error , и тот же репо на github.com, но без этой ошибки. Поэтому я просто клонировал репо, работающее с github, а затем скопировал все из поврежденного репо (кроме папки .git) и вставил клонированное репо, которое работает.

Это может быть не практичным решением (поскольку вы удаляете локальные коммиты), однако вы сохраняете код и исправленный контроль версий.

Не забудьте сделать резервную копию перед применением этого подхода.

В моем случае мне было не важно вести историю локальных коммитов. Так что, если это относится и к вам, вы можете сделать это в качестве быстрой альтернативы решениям выше:

Вы просто заменяете поврежденный .git/каталог на чистый.

Предположим, что следующий каталог для вашего проекта с испорченным git: projects/corrupt_git/

1. cp projects/corrupt_git projects/backup - (необязательно) сделать резервную копию
2. git clone [repo URL] projects/clean_git - так что вы получите projects/clean_git
3. rm -rf corrupt_git/.git/ удалить поврежденную папку .git
4. mv clean_git/.git/ corrupt_git/ - переместить чистый мерзавец в corrupt_git/.git
5. git statusв projects/corrupt_git- чтобы убедиться, что это сработало

Скопируйте все (в папке, содержащей .git) в резервную копию, затем удалите все и перезапустите. Убедитесь, что у вас есть под рукой git remote:

git remote -v
 origin git@github.com:rwldrn/idiomatic.js.git (fetch)
 origin git@github.com:rwldrn/idiomatic.js.git (push)

затем

mkdir mygitfolder.backup
cp mygitfolder/* mygitfolder.backup/
cd mygitfolder
rm -r * .git*
git init
git remote add origin git@github.com:rwldrn/idiomatic.js.git

Затем объедините все новые файлы вручную и попробуйте включить компьютер.

Была такая же проблема после проверки мастера из чистой ветки. Через некоторое время я узнал много модифицированных файлов в мастере. Я не знаю, почему они были там, после переключения с чистой ветки. В любом случае, потому что измененные файлы не имели смысла для меня, я просто спрятал их, и ошибка исчезла.

git:(master) git stash

если у вас есть старая резервная копия и вы спешите:

создайте НОВОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ вашего текущего пути проекта.

1. переместить .gitв корзину (никогда не удаляйте)
2. скопировать .gitиз старой резервной копии
3. git pull (создаст конфликты слияния)
4. переместить все ваши источники (все, что вы положили в git) в корзину: ./src (никогда не удаляйте)
5. скопируйте все ваши исходники (все, что вы положили в git) из NEW BACKUP
6. примите все "слияния" git gui, нажмите и ... хлопайте в ладоши!

Решение из двенадцати шагов, описанное выше, также помогло мне выйти из затора. Спасибо. Ключевые шаги должны были войти:

git fsck --full 

и удалите все пустые объекты

rm .git/objects/...

Затем получим две строки с поркой:

tail -n 2 .git/logs/refs/heads/master

С возвращенными значениями

git update-ref HEAD ...

В этот момент у меня больше не было ошибок, поэтому я сделал резервную копию своих самых последних файлов. Затем сделайте git pull с последующим git push. Скопировал мои резервные копии в мой файл репозитория git и сделал еще один толчок git. Это актуально для меня.

Я исправил ошибку в git: объектный файл пуст:

1. Сохранение копии всех файлов, которые я редактировал со времени моего последнего успешного коммита / толчка,
2. Удаление и повторное клонирование моего хранилища,
3. Замена старых файлов моими отредактированными файлами.

Надеется, что это помогает.

Это также случается со мной почти регулярно. Я не сделал протокол, когда это происходит точно, но у меня есть подозрение, что это происходит всякий раз, когда моя виртуальная машина существует «неожиданно». Если я закрываю окно виртуальной машины (я использую Ubuntu 18.04) и начинаю снова, все всегда (?) Работает. Но если окно виртуальной машины все еще открыто, когда мой ноутбук выключен (хост-система Windows), то я сталкиваюсь с этой проблемой довольно часто.

Что касается всех ответов, приведенных здесь:

1. спасибо - они очень полезны; Я обычно сохраняю локальную копию своего кода, восстанавливаю репозиторий с удаленного компьютера и перемещаю резервную копию обратно в локальную папку.

2. так как основная проблема на самом деле не проблема git, а проблема виртуальной машины и / или Linux, мне интересно, не должен ли быть способ излечить причину, а не симптомы? Разве такого рода ошибки не указывают на то, что некоторые изменения файловой системы не «применяются» в любое разумное время, а только кэшируются? (см., например, /unix/464184/are-file-edits-in-linux-directly-saved-into-disk ) - мне кажется, что виртуальные машины Linux не fsynch их вещи достаточно часто. Вопрос о том, является ли это проблемой Oracle VirtualBox (которая в остальном работает очень хорошо) или гостевой файловой системы, или некоторых настроек, которые мы все пропускаем, не входит в мои компетенции. Но я был бы счастлив, если бы кто-то мог пролить свет на это.

На самом деле у меня была такая же проблема. Имейте копию своего кода, прежде чем пытаться это.

я только что сделал git reset HEAD~

мой последний коммит был отменен, потом я его повторил, проблема решена!

Предупреждение: Имея больше опыта, я понимаю, что это ядерный вариант, и его обычно не следует делать, и он ничему не учит. Однако в редких случаях для личных проектов я все еще находил это полезным, поэтому я оставляю это.

Если вы не заботитесь о сохранении своих исторических коммитов, просто бегите

rm -r .git

Затем ответьте «да» на все вопросы об удалении файлов, защищенных от записи. Проблема решена в течение минуты.