这个错误发生在我推动我的提交和我的计算机挂起。

这就是我解决它的方法。

修复步骤

git status

显示空/损坏的目标文件

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

删除它

git status

我得到了致命的:坏对象头部消息

rm .git/index

我移除重置的索引。

git reset

无法解析对象“HEAD”。

git status
git pull

看看发生了什么

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

它输出log分支的最后两行，tail - n2，来显示最后两次提交哈希值。

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

我选择最后一个提交哈希

git status

它显示我所有的文件都已删除，因为我删除了.git/index文件

git reset

继续复位

git status

验证我的修复

我和我的同事多次遇到同样的问题，为了解决这个问题，我们简单地按照下面描述的步骤来做。这不是最优雅的解决方案，但它不会丢失数据。

重命名当前工作目录。(本例中的old_project)。 使用git Clone在新目录中克隆存储库。 在命令行上，将工作目录更改为新创建的项目，并切换到您一直在工作的分支。 将old_project中的所有文件和目录(.git目录除外)复制到新创建的项目目录中。 检查您的工作树状态(注意有比您期望的更多的更改)，然后提交更改。

我希望它能有所帮助……

在我的虚拟机崩溃和Git文件损坏后，我也有同样的问题。

第一步，从项目的根文件夹。

find .git/objects -type f -empty -delete

然后是西梅和fetch…

git prune
git fetch --all --prune

然后做了一些回滚，然后就开始工作了。

复制所有文件(在包含.git文件夹的文件夹中)到备份，删除所有文件，然后重新启动。确保你手边有Git遥控器:

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

Then

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

然后手动合并任何新文件，并试着让你的电脑开着。

这个问题的解决方法很简单

•找到那个文件

•就像我的情况一样

error: object file .git/objects/f1/a0e726cd3505a9be8dffaa78077dfe3a497eaf is empty
fatal: loose object f1a0e726cd3505a9be8dffaa78077dfe3a497eaf (stored in .git/objects/f1/a0e726cd3505a9be8dffaa78077dfe3a497eaf) is corrupt

然后直接删除 a0e726cd3505a9be8dffaa78077dfe3a497eaf

Or

rm .git/objects/f1/a0e726cd3505a9be8dffaa78077dfe3a497eaf

这种情况也经常发生在我身上。我没有制定具体何时发生这种情况的协议，但我怀疑每当我的虚拟机(VM)“意外”存在时就会发生这种情况。如果我关闭虚拟机窗口(我使用的是Ubuntu 18.04 (Bionic Beaver))并重新开始，事情总是(?)工作。但是如果当我的笔记本电脑关闭(Windows主机系统)时，虚拟机窗口仍然打开，那么我经常遇到这个问题。

对于这里给出的所有答案:

thank you - they are very useful; I usually save a local copy of my code, restore the repository from remote, and move the backup copy back into the local folder. as the underlying problem is not really a Git issue, but rather a VM and/or Linux issue, I wonder if there shouldn't be a way to cure the reason rather the symptoms? Doesn't this kind of error indicate that some file system changes are not "applied" in any reasonable time, but only cached? (see for example Are file edits in Linux directly saved into disk?) -- to me it appears as if virtual Linux machines don't fsynch their stuff frequently enough. Whether this is an issue of Oracle's VirtualBox (which otherwise works very nicely) or of the guest file system, or of some settings, which we all overlook, is beyond my expertise. But I would be happy if someone could shed light on this.