Як виправити помилку GIT: об’єктний файл порожній?

Коли я намагаюся внести зміни, я отримую цю помилку:

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

Будь-яка ідея, як вирішити цю помилку?

EDIT

Я спробував git fsck:

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

У мене була схожа проблема. У мого ноутбука вичерпалася батарея під час роботи git. Бу

У мене не було резервних копій. (Примітка. Ubuntu One не є резервним рішенням для git; це допоможе перезаписати ваше здорове сховище зі своїм пошкодженим.)

Для майстрів 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. Знайдіть це . Вручну дістаньте останні два рядки рефлогу:

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

fatal: Не вдалося розібрати об’єкт '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.

Мені прикро, що зараз навіть коли файлові системи впроваджують журнал та інші "трансакційні" методи, щоб зберегти fs здоровим, git може перейти в пошкоджений стан (і не зможе відновитись сам) через відключення електроенергії або місця на пристрої.

У мене просто виникло те саме питання: після витягування віддаленого сховища, коли я робив статус git, я отримав: "помилка: файл об'єкта (...) порожній" "фатально: вільний об'єкт (...) пошкоджений"

Я вирішив це:

1. git stash
2. видалення файлу git помилково (не впевнений, що це необхідно)
3. git stash clear

Я не знаю точно, що сталося, але ця інструкція, здавалося, робить все чистою.

Тому що мені доводиться перезавантажувати свій VM регулярно, тому якось ця проблема трапляється зі мною дуже часто. Після кількох разів я зрозумів, що не можу повторювати процес, описаний @ 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 )
2. git clone your_repository
3. Нарешті,. Відкрийте інструмент злиття (я використовую meld diff viewer linux або Winmerge Windows) і скопіюйте зміни праворуч ( app_folder_bk ) вліво (новий додаток_папка ) (це як застосовано скрипт git ).

Це все. Можливо, це не найкращий спосіб, але я думаю, що це так практично.

У моєму випадку ця помилка сталася через те, що я набирав повідомлення про фіксацію, а мій ноутбук вимкнено.

Я зробив ці кроки, щоб виправити помилку:

• 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 # Видалити гілку локально ("ваша гілка" - це гілка з проблемою)
• 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 перенаправляє повідомлення про помилку до stdout, щоб мати змогу визначити його
• використовуються варіанти грепа:
  • -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 repo

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 (я працюю з композитором та 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/ - перейти чистий git до corrupt_git/.git
5. git statusв projects/corrupt_git- щоб переконатися, що це спрацювало

Скопіюйте все (у папку, що містить .git) у резервну копію, потім видаліть усе та перезапустіть. Переконайтеся, що у вас git віддалений:

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

Потім об'єднайте будь-які нові файли вручну та спробуйте ввімкнути комп'ютер.

Була така ж проблема після перевірки майстра з чистої гілки. Через деякий час я впізнав багато модифікованих файлів у master. Я не знаю, чому вони там були, після переходу з чистої гілки. У будь-якому разі, оскільки змінені файли для мене не мали сенсу, я просто приховав їх, і помилка не стала.

git:(master) git stash

якщо у вас є СТАРА резервна копія і поспішає:

Створіть НОВУ РОЗВИТКУ ваш поточний шлях до проекту.

1. перемістіть своє .git кошик (ніколи не видаляти)
2. копія .gitз резервної копії OLD
3. git pull (створить конфлікти злиття)
4. перемістіть усі свої джерела (усе, що ви поклали в git) у кошик: ./src (ніколи не видаляйте)
5. .копіюйте всі свої джерела (все, що ви вкладаєте в git) з НОВОГО ЗАПАСУ
6. прийміть всі "злиття" на git gui, натисніть і ... плескайте в руки!

Розкритий вище крок дванадцяти кроків допоміг і мені позбутися варення. Дякую. Ключові кроки:

git fsck --full 

і видаліть усі порожні об’єкти

rm .git/objects/...

Тоді отримуємо два рядки колу:

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

З поверненими значеннями

git update-ref HEAD ...

На цей момент у мене більше не було помилок, тому я зробив резервну копію своїх останніх файлів. Потім зробіть потяг git з подальшим натисканням git. Скопіював резервні копії у мій файл сховища git та здійснив ще один натискання git. Це мене актуально.

Я виправив свою помилку в git: об’єктний файл порожній:

1. Збереження копії всіх файлів, які я редагував з мого останнього успішного виконання / натискання,
2. Видалення та повторне клонування мого сховища,
3. Заміна старих файлів на мої редаговані файли.

Сподіваємось, що це допомагає.

Це теж трапляється зі мною майже регулярно. Я не склав протокол, коли це відбувається саме так, але у мене є підозра, що він виникає кожного разу, коли моя віртуальна машина існує "несподівано". Якщо я закрию вікно VM (я використовую Ubuntu 18.04) і запускаю знову, все завжди працює (?). Але якщо вікно VM все ще відкрите, коли мій ноутбук вимикається (хост-система Windows), я стикаюся з цією проблемою досить часто.

Щодо всіх відповідей, наведених тут:

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

2. оскільки основна проблема насправді не є проблемою git, а скоріше проблемою VM та / або Linux, мені цікаво, чи не повинен бути спосіб вилікувати причину, а не симптоми? Чи не вказує така помилка, що деякі зміни файлової системи не "застосовуються" в будь-який розумний час, а лише кешуються? (див., наприклад, /unix/464184/are-file-edits-in-linux-direct-saved-into-disk ) - мені здається, ніби віртуальні машини Linux не роблять обробляти їх речі досить часто. Чи це питання VirtualBox Oracle (який інакше працює дуже добре), або гостьова файлова система, або деякі налаштування, які ми всі не помічаємо, не вдається мені. Але я був би радий, якби хтось міг пролити на це світло.

Насправді у мене була така ж проблема. Перед тим, як спробувати, отримайте копію коду.

я тільки що зробив git reset HEAD~

моє останнє зобов’язання було скасовано, тоді я знову здійснив це, проблема вирішена!

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

Якщо ви не хочете зберігати свої історичні зобов’язання, просто запустіть

rm -r .git

Потім відповідь "так" на все запитання про видалення файлів, захищених від запису. Проблема вирішена за менше хвилини.