我刚遇到过这样的问题。我的特殊问题是由系统崩溃引起的，它破坏了最近的提交(因此也破坏了主分支)。我没有强迫自己，想要重新做出承诺。在我的特殊情况下，我可以这样处理:

Make a backup of .git/: rsync -a .git/ git-bak/ Check .git/logs/HEAD, and find the last line with a valid commit ID. For me, this was the second most recent commit. This was good, because I still had the working directory versions of the file, and so the every version I wanted. Make a branch at that commit: git branch temp <commit-id> re-do the broken commit with the files in the working directory. git reset master temp to move the master branch to the new commit you made in step 2. git checkout master and check that it looks right with git log. git branch -d temp. git fsck --full, and it should now be safe to delete any corrupted objects that fsck finds. If it all looks good, try pushing. If that works,

这对我很管用。我怀疑这是一个相当常见的场景，因为最近的提交是最有可能被损坏的，但如果你丢失了一个更早的提交，你可能仍然可以使用这样的方法，小心地使用git cherrypick，并在.git/logs/HEAD中reflog。

垃圾收集解决了我的问题:

git gc --aggressive --prune=now

它需要一段时间才能完成，但是每个松散的对象和/或损坏的索引都是固定的。

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

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

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

当我遇到这个问题时，我备份了我最近的更改(因为我知道我已经更改了什么)，然后删除了它在.git/location中抱怨的文件。然后我做了一个“少不再来”的动作。不过要小心，这可能不适合你。

我在写提交信息的时候电脑死机了。重新启动后，工作树就像我离开时一样，我能够成功提交我的更改。

然而，当我试图运行git状态时，我得到了

error: object file .git/objects/xx/12345 is empty
fatal: loose object xx12345 (stored in .git/objects/xx/12345 is corrupt

与大多数其他答案不同，我并没有试图恢复任何数据。我只是需要Git停止抱怨空对象文件。

概述

“目标文件”是Git对您所关心的实际文件的散列表示。Git认为它应该有一个/文件的散列版本。无论存储在.git/object/xx/12345中的是什么，修复这个错误基本上就是找出“松散对象”应该表示哪个文件的问题。

细节

可能的选择似乎是

删除空文件 将文件转换为Git可以接受的状态

方法1:删除目标文件

我尝试的第一件事就是移动object文件

mv .git/objects/xx/12345 ..

但这并没有起作用——Git开始抱怨断开的链接。关于方法二。

方法2:修复文件

Linus Torvalds写了一篇关于如何恢复目标文件的文章，为我解决了这个问题。这里总结了关键步骤。

$> # Find out which file the blob object refers to
$> git fsck
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
           to    blob xx12345
missing blob xx12345

$> git ls-tree 2d926
...
10064 blob xx12345    your_file.whatever

这告诉你空对象应该是哪个文件的哈希值。现在你可以修理了。

$> git hash-object -w path/to/your_file.whatever

在这样做之后，我检查了. Git /objects/xx/12345，它不再是空的，Git停止抱怨。

我也有同样的问题在我的裸远程git回购。经过大量的故障排除后，我发现我的一个同事提交了。git/objects中的一些文件的权限是440 (r—r-----)，而不是444 (r—r—r—)。在让同事用“chmod 444 -R objects”在裸git repo中更改权限后，问题得到了解决。