当我的系统崩溃时，我遇到了这种情况。我所做的是:

(请注意，您的损坏提交将丢失，但更改将保留。你可能必须在这个过程结束时重新创建这些提交)

备份代码。 转到您的工作目录并删除.git文件夹。 现在将远程复制到另一个位置，并在其中复制.git文件夹。 将其粘贴到工作目录中。 做你想做的事。

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

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

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

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

只需删除。git文件夹并重新添加。这个简单的解决方法对我很有效。

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

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。

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

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