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のバックアップソリューションではありません。正常なリポジトリを破損したリポジトリで上書きすると便利です。）

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の最後の2行を手動で取得します。

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ポインターは、（現在は古い）インデックスファイル（source）からのものであるように見えました。だから私はそれを殺してレポをリセットしました。

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

tail -n 2ログブランチの最後の2行を印刷して、最後の2行を表示しますcommit 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 stashのようなものです）
2. git clone your_repository
3. 最終的に、。マージツールを開き（私はmeld diff viewer linuxまたはWinmerge Windowsを使用しています）、変更をright（app_folder_bk）からleft（new app_folder）にコピーします（これはgit stash applyのようなものです）。

それで全部です。多分それは最善の方法ではありませんが、それはとても実用的だと思います。

私の場合、このエラーは、コミットメッセージを入力していて、ノートブックがオフになっているために発生しました。

エラーを修正するために次の手順を実行しました。

• git checkout -b backup-branch ＃バックアップブランチを作成する
• git reset --hard HEAD~4＃すべてがうまく機能するコミットにリセットします。私の場合、私は頭の中で4つのコミットを取り消さなければなりませんでした。つまり、コミットメッセージを入力する前の時点まで頭を下げていました。この手順を実行する前に、リセットするコミットのハッシュをコピーします。私の場合、最後の4つのコミットのハッシュをコピーしました。
• git cherry-pick <commit-hash> ＃Cherryは、古いブランチから新しいブランチにリセットされたコミット（私の場合は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

私の問題を解決する

ここでは、この問題に対処するための本当に簡単かつ迅速な方法であるのIFあなたが必要なすべての支店やコミットでローカルレポを持っているが、あなたの新しいレポを作成（または、サーバーのレポを削除し、新しいものを作るとしているOKであればその代わりに）：

1. サーバー上に新しい空のリポジトリを作成します（または古いリポジトリを削除して、代わりに新しいリポジトリを作成します）。
2. ローカルコピーのリモートURLを、新しいリポジトリのリモートURLを指すように変更します。
3. ローカルリポジトリから新しいサーバーリポジトリにすべてのブランチをプッシュします。

これにより、ローカルリポジトリにあったすべてのコミット履歴とブランチが保持されます。

リポジトリに共同編集者がいる場合、多くの場合、共同編集者がしなければならないことは、ローカルリポジトリのリモートURLも変更し、オプションで、サーバーにないコミットをプッシュすることだけだと思います。

この同じ問題に遭遇したとき、この解決策は私にとってうまくいきました。私にはコラボレーターが一人いました。ローカルリポジトリを新しいリモートリポジトリにプッシュした後、リモートリポジトリのURLを指すようにローカルリポジトリを変更しただけで、すべてが正常に機能しました。

私は、関連するすべての変更がすでにプッシュされているリモートを持っていると想定しています。私はローカルの変更については気にせず、単に大きなリポジトリを削除して再クローンすることを避けたかっただけです。ローカルで重要な変更がある場合は、さらに注意する必要があります。

ラップトップがクラッシュした後も同じ問題がありました。おそらくそれが大きなリポジトリだったため、を呼び出したときに一度に1つしか表示されないかなりの数の破損したオブジェクトファイルがあったgit fsck --fullため、小さなシェルのワンライナーを作成して、それらの1つを自動的に削除しました。

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

• 2>&1 エラーメッセージをstdoutにリダイレクトして、grepできるようにします
• 使用されるgrepオプション：
  • -o 実際に一致する行の一部のみを返します
  • -E 高度な正規表現を有効にします
  • -m 1 最初の一致のみが返されることを確認してください
  • [0-9a-f]{2} 2つが同時に出現する場合、0から9およびaとfの間の文字のいずれかに一致します
  • [0-9a-f]* 0から9までの任意の数の文字に一致し、aとfが一緒に出現する

それでも、一度に1つのファイルしか削除されないため、次のようなループで呼び出すことができます。

$ 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を確認してください

   git fsck --full
   

3. 空のオブジェクトファイルを削除する（すべて）

   rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
   

4. もう一度gitを確認してください。

   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

その後、エラーの前のポイントにいる必要があります。

お役に立てれば。

よろしく。

同じ問題が発生し、非常に簡単な方法で修正しています。チームメイトのコンピューターにこれらの欠落ファイルが存在することがわかりました。

それらのファイルを1つずつ gitサーバーにコピーし（合計9ファイル）、問題を修正しました。

私の同僚と私はこれと同じ問題を何度か経験しましたが、それを解決するには、以下で説明する手順を実行するだけです。見つけることができる最もエレガントなソリューションではありませんが、データを失うことなく機能します。

1. 現在の作業ディレクトリの名前を変更します。（old_projectこの例では）。
2. を使用して、新しいディレクトリ内にリポジトリのクローンを作成しますgit clone。
3. コマンドラインで、作業ディレクトリを新しく作成したプロジェクトに変更し、作業していたブランチに切り替えます。
4. old_project（ディレクトリを除く.git）内のすべてのファイルとディレクトリを、新しく作成されたプロジェクトディレクトリにコピーします。
5. 作業ツリーのステータスを確認し（予想よりも多くの変更があることに注意してください）、変更をコミットします。

それが役に立てば幸い...

github.comのパブリックリポジトリは機能しているが、ローカルリポジトリが破損している場合に問題を解決する方法を次に示します。ローカルリポジトリで行ったすべてのコミットが失われることに注意してください。

申し分なく、私はこれを私に与えている1つのリポジトリをローカルに持っています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

古いバックアップがあり、急いでいる場合：

現在のgitが壊れたプロジェクトパスの新しいバックアップを作成します。

1. .gitゴミ箱に移動します（削除しないでください）
2. .git古いバックアップから コピー
3. git pull （マージの競合が発生します）
4. すべてのソース（gitに入れたものすべて）をゴミ箱に移動します：（./src 削除しないでください）
5. 新しいバックアップからすべてのソース（gitに入れたものすべて）をコピーします。
6. ですべての「マージ」を受け入れgit gui、プッシュして...手をたたいてください！

上記で説明した12ステップのソリューションは、私を渋滞から救うのにも役立ちました。ありがとう。主な手順は次のとおりです。

git fsck --full 

空のオブジェクトをすべて削除します

rm .git/objects/...

次に、flogの2行を取得します。

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

戻り値

git update-ref HEAD ...

この時点でエラーは発生していなかったので、最新のファイルのバックアップを作成しました。次に、git pullを実行してから、git pushを実行します。バックアップをgitリポジトリファイルにコピーし、別のgitプッシュを実行しました。それは私を最新のものにしました。

私は私のgitエラーを修正しました：オブジェクトファイルは空です：

1. 最後に成功したコミット/プッシュ以降に編集したすべてのファイルのコピーを保存します。
2. リポジトリの削除と再クローン、
3. 古いファイルを編集したファイルで置き換えます。

これがお役に立てば幸いです。

これもほぼ定期的に起こります。これが正確に行われるときにプロトコルを作成していませんが、仮想マシンが「予期せず」存在するときに必ずプロトコルが発生するという疑いがあります。VMウィンドウを閉じて（Ubuntu 18.04を使用しています）再度起動すると、常に（？）が機能します。しかし、ラップトップをシャットダウンしたときにVMウィンドウがまだ開いている場合（Windowsホストシステム）、この問題はかなり頻繁に発生します。

ここに与えられたすべての答えについて：

1. ありがとう-彼らは非常に便利です。通常、コードのローカルコピーを保存し、リモートからリポジトリを復元して、バックアップコピーをローカルフォルダーに戻します。

2. 根本的な問題は実際にはgitの問題ではなく、VMやLinuxの問題なので、症状ではなく理由を解決する方法がないのではないでしょうか。この種のエラーは、一部のファイルシステムの変更が妥当な時間内に「適用」されず、キャッシュのみされることを示していませんか？（たとえば、https：//unix.stackexchange.com/questions/464184/are-file-edits-in-linux-directly-saved-into-diskを参照してください）-私には、仮想Linuxマシンにはないように見えます十分頻繁にそれらのものをfsynchします。これがOracleのVirtualBox（他の方法では非常にうまく機能する）の問題か、ゲストファイルシステムの問題なのか、私たち全員が見落としている設定の問題なのかは、私の専門知識を超えています。しかし、誰かがこれに光を当てることができれば幸いです。

実際、同じ問題がありました。これを試す前に、コードのコピーを用意してください。

今やりました git reset HEAD~

私の最後のコミットは元に戻され、それからもう一度コミットしました、問題は解決しました！

警告：これまでの経験から、これは核のオプションであり、通常は行うべきではなく、何も教えていないことに気づきました。ただし、個人的なプロジェクトのまれなケースでは、私はそれがまだ有用であることに気付いていたので、それはそのままにしておきます。

履歴のコミットを維持する必要がない場合は、次を実行してください

rm -r .git

次に、書き込み保護されたファイルの削除について質問があれば、yesと答えます。問題は1分以内に解決されました。