复制所有文件(在包含.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

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

这里有一个非常简单和快速的方法来处理这个问题，如果你有一个本地回购和所有你需要的分支和提交，如果你可以创建一个新的回购(或删除服务器的回购并在它的位置上创建一个新的):

在服务器上创建一个新的空回购(或删除旧的回购并在其位置上创建一个新的回购) 将本地副本的远程URL更改为指向新回购的远程URL。 将所有分支从本地回购推到新的服务器回购。

这将保存您在本地回购中拥有的所有提交历史和分支。

如果你在回购上有合作者，那么我认为在很多情况下，你的合作者所要做的就是改变他们本地回购的远程URL，并有选择地推送任何他们拥有的服务器没有的提交。

当我遇到同样的问题时，这个解决方案对我很有效。我有一个合作者。在我将本地回购推到新的远程回购后，他只是将本地回购更改为指向远程回购URL，一切都正常工作。

在这种情况下，我通过遵循这个问题来解决我的问题。

从存储库目录中删除。git文件夹。(为安全起见保留备份) 克隆我的回购在另一个目录。 从新的克隆目录复制.git文件夹。 粘贴到之前出现问题的目录中。

检查git状态，希望你能看到你所有的变化。现在你可以承诺并推进了。

Git对象文件已经损坏(正如在其他回答中指出的那样)。这可能发生在机器崩溃等情况下。

我也有同样的问题。在阅读了这里的其他顶级答案之后，我发现了修复损坏的Git存储库的最快方法，使用以下命令(在包含.git文件夹的Git工作目录中执行):

(请务必先备份Git存储库文件夹!)

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

这将首先删除导致整个存储库损坏的所有空对象文件，然后从远程存储库获取缺失的对象(以及最新的更改)，然后执行完整的对象存储检查。在这一点上，它应该成功而没有任何错误(尽管仍然可能有一些警告!)

PS:这个答案表明你有一个Git存储库的远程副本 在某个地方(例如在GitHub上)，损坏的存储库是本地存储库，它绑定到仍然完整的远程存储库。如果不是这样，那么不要尝试用我推荐的方法来修复它。

我解决了这个问题，删除了git fsck检测到的各种空文件，然后运行一个简单的git拉。

我感到失望的是，现在即使文件系统实现了日志记录和其他“事务性”技术来保持文件系统正常运行，Git也会因为设备上的电源故障或空间问题而进入损坏状态(并且无法自行恢复)。

这种情况也经常发生在我身上。我没有制定具体何时发生这种情况的协议，但我怀疑每当我的虚拟机(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.