当在同一个git签出中使用不同版本的不同git客户端时，通常会出现此问题。认为:

命令行 IDE内置git docker / vm容器内部 GIT gui工具

确保您使用创建提交的同一客户端进行推送。

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

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。

最好的办法可能是简单地从远程存储库(即GitHub或其他)重新克隆。不幸的是，你将失去任何未推送的提交和隐藏的更改，但你的工作副本应该保持完整。

首先对本地文件进行备份。然后从你的工作树的根开始:

rm -fr .git
git init
git remote add origin [your-git-remote-url]
git fetch
git reset --mixed origin/master
git branch --set-upstream-to=origin/master master

然后根据需要提交任何更改过的文件。

这里有个箱子。碰巧的是，问题是损坏文件的所有权是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/

希望能有所帮助!

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

git gc --aggressive --prune=now

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

我是这样解决的: 我决定简单地将未损坏的对象文件从备份的克隆复制到原始存储库。这个方法同样有效。(顺便说一下:如果你在.git/objects/中找不到它的名字，它可能已经被[打包][包]以节省空间。)