这个问题可能是一个很长的问题，因为我仍然无法可靠地复制这个问题，但它已经多次发生在我的几个同事身上，它仍然让我感到困惑。
有时 Git 扩展（在 Windows 7 上）会在提交和推送后在其工作目录中显示不属于他们自己的待处理更改。推送失败是因为它说他们有待处理的更改，尽管事实上他们在推送之前几乎没有提交所有待处理的更改。这就是我被召唤的时候。在检查更改后，它们是由另一个提交者所做的更改并推送到原始位置。几次更改甚至是我所做的更改。
开发者 A（我们称之为 Bob）继续对他的存储库进行了一系列更改。Bob 然后提交这些更改并将提交推送到原点。
开发人员 B（将称为 Fred）也进行了一些更改并将它们提交到他的存储库。然后 Fred 尝试将这些更改推送到原点。在这一点上，我预计 Fred 会收到一个错误，说他的存储库在 1 次提交之后落后于原点，并告诉他先进行拉取。但是，他收到的错误是推送失败，因为他的工作目录中有待处理的更改。当 Fred 查看待处理的更改时，他发现所有更改实际上都是在 Bob 的提交中所做的更改。
当 Fred 将这些更改视为自己的更改时，一切似乎都很好。没有什么可以打破它，但它发生时非常奇怪。如果我们尝试撤消挂起的更改，我还没有看到会发生什么，因为我担心如果我们这样做，这些更改基本上会被还原。
有没有其他人在使用 Git 或 Git 扩展时遇到过这种奇怪的行为？
更新
我在我们的项目历史中发现了一个发生这种情况的实例。两次提交都对相同数量的文件进行了完全相同的更改，但提交是由两个不同的开发人员完成的。
这是 Bob 的原始提交：
这是 Fred 的不稳定提交：
编辑：为了澄清，Fred 的意思是输入“推送更改”作为提交消息，因为它是尝试推送（而不是拉取）的行为导致了神秘的挂起更改出现。