对我来说，这是由于在做git推时发生的电源故障。

这些信息是这样的:

$ git status
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
fatal: loose object c238824eb3fb602edc2c49fccb535f9e53951c74 (stored in .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74) is corrupt

我尝试了git fsck之类的东西，但这没有帮助。 由于崩溃发生在git推送期间，它显然发生在客户端重写期间，发生在服务器更新之后。我环顾四周，发现c2388在我的例子中是一个提交对象，因为它是由.git/refs中的条目引用的。所以我知道，当我查看历史(通过web界面或第二个克隆)时，我将能够找到c2388。

在第二个克隆中，我执行了git log -n 2 c2388来识别c2388的前身。然后我手动修改了.git/refs/heads/master和.git/refs/remotes/origin/master作为c2388的前身，而不是c2388。 然后我可以进行git取回。 git获取失败了几次，因为空对象上的冲突。我删除了这些空对象，直到git获取成功。这已经修复了存储库。

Felipe Pereira(上图)提供的解决方案，加上Stephan对我在对象被损坏时所在分支名称的回答的评论，对我来说是有效的。

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin
git symbolic-ref HEAD refs/heads/${BRANCH_NAME}

这里有个箱子。碰巧的是，问题是损坏文件的所有权是root而不是我们的正常用户。这是由于在有人执行了“sudo su——”之后在服务器上进行的提交造成的。

首先，用以下方法识别损坏的文件:

$> git fsck --full

你应该会收到这样的回答:

fatal: loose object 11b25a9d10b4144711bf616590e171a76a35c1f9 (stored in .git/objects/11/b25a9d10b4144711bf616590e171a76a35c1f9) is corrupt

进入损坏文件所在的文件夹，并执行以下操作:

$> ls -la

检查损坏文件的所有权。如果这是不同的，只要回到你的回购的根，并执行:

$> sudo chown -R YOURCORRECTUSER:www-data .git/

希望能有所帮助!

我遵循了这里的许多其他步骤;Linus对如何查看git树/对象并找到缺失内容的描述尤其有用。git恢复损坏的blob

但最后，对我来说，由于部分磁盘故障，我有松散/损坏的树对象，并且树对象不容易恢复/不被那个文档覆盖。

最后，我将冲突的对象/<ha>/<hash>移出，并使用git unpack-objects与最新克隆的包文件一起使用。它能够恢复丢失的树对象。

仍然给我留下了许多悬空的斑点，这可能是解压缩以前存档的东西的副作用，并在这里的其他问题中解决

看起来您有一个损坏的树对象。您需要从其他人那里获取该对象。希望他们会有一个未损坏的版本。

如果您无法从其他人那里找到有效的版本，您可以通过猜测应该在那里的文件来重新构建它。您可能想要查看对象的日期和时间是否与它匹配。这些可能是相关的斑点。您可以从这些对象推断出树对象的结构。

看看Scott Chacon关于Git内部的截图。这将向您展示git在引子下是如何工作的，以及如果您真的卡住了，并且无法从其他人那里获得该对象，如何进行此侦探工作。

运行git stash;Git stash pop解决了我的问题