我和其他几个人一起使用git。我们有一个中央存储库，然后是本地跟踪分支。最近，我们遇到了一个问题，git会错误地认为主分支和新分支的最后一个共同祖先提交是在我们创建新分支后才推送的提交，导致在我们合并时撤消更改新分支回来了。例如：
Alice在主分支的本地副本中进行了一些更改并提交了它们，但是没有推送。假设她改变了文件foo.txt的第一行。
鲍勃从主分支的中央副本拉出来。据他所知，他是最新的。两者都继续发挥作用。在某些时候，爱丽丝推了推。后来，Bob调用git log并发现他的分支据称是Alice更改foo.txt的提交的祖先，即使他从未撤消过她的更改。当Bob按预期合并时，Alice的更改已经消失。
我一直无法重现这一点，但可以从日志中看出它确实在某一时刻发生过（即我们有一个分支据称是提交的继承者，其中对源文件进行了更改，但是其中没有那些变化）。这种事情怎么可能，我怎么能阻止它？
答案 0 :(得分：2)
有人在某个阶段强制推送一些更改并覆盖特定的哈希提交（在推送中使用-f）。这听起来像你的情况会发生这种情况。
如果这对你有帮助，我们的工作流程就是在拉/推时始终使用rebase：
A人做了改变并推动他们。
B人继续工作，做本地提交
在某个阶段，B人想要推送。要做到这一点。
B人确保本地分支是干净的（如果没有，则藏匿）。
B人运行git pull --rebase（这将下载所有更改并在新HEAD上重新应用）
如果有任何冲突，B人将解决冲突。
B人最终推出本地副本。
并重新应用相同的过程，其中人A是原始头后面的人并且需要拉动底板
在推动现场时永远不要使用-f，这真的很糟糕。
更多信息：当A人做了提交，将其推送，然后意识到还有一个错误时，强制推动很诱人。 A人对最后一次提交做了修改。然后推送这个提交的唯一方法就是做一个push -f ...这对那些在他们自己的副本上工作的人来说非常糟糕，他们已经对他们的副本进行了本地提交并推动了实时