在大多数情况下，我的问题在这里得到了完整的回答：Git Merging - what happens to 2 branches being merged at same time 我好奇的一小部分是鲍勃的代码在这种情况下会发生什么。由于Alice首先进入那里，因此他无法合并所做的更改，因此现在他的本地Master分支与origin分支不同步，因此他被迫执行拉取或提取操作以使他的本地分支重新回到行中与原产地/母公司。他在本地所做的更改会怎样？当然，如果他再次从母带那里拉过来，他的更改现在不是在本地覆盖吗？
[编辑] 我本来可以说得更好。我认为我要寻找的是在链接的场景中，两个用户都在同一个文件上，而Bob更改了文件的第2行。爱丽丝还更改了其分支中的第2行。爱丽丝首先获得了合并。鲍勃在本地提交所有更改，并尝试将其更改合并到源/主服务器。由于原点/母版已更改，因此失败，因此他被迫再次从原点/母版撤出。完成后，他的本地主副本将包含Alice的更改。现在，他被迫再次提交以将更改提交给新的本地主服务器，然后可以将其合并回原点/主服务器。
我理解正确吗？
答案 0 :(得分：0)
由于爱丽丝先进入那里，所以他无法合并自己的更改...
这就是您的问题出在哪里。他可以合并，因为他还没有Alice的合并。由于爱丽丝击败了他，他无法成功完成的工作是git push他与另一位Git的合并。
git push失败了，鲍勃必须退后一步运行git fetch。现在，鲍勃拥有（并且必须遵守）爱丽丝的合并。如果Bob选择遍历所有内容，那么他可以在 his 存储库中覆盖Alice的合并-毕竟Bob的存储库是Bob想要的，并且可以按照Bob的意愿进行处理-但如果他使用默认机制Git提供的共享工作，他将：
git rebase -i轻松完成此操作），然后与Alice的合并重新合并，或者这三种方法都倾向于自动成功，或者存在冲突，其中鲍勃可能是最有能力找出正确解决方案的人。结果是Bob现在可以成功git push，而无需使用--force。
让我们再次考虑这三种情况：
基于Alice的合并。
在这里，Bob选择用新的和改进的基于基础的提交（在Alice的工作之后）代替他以前的一系列提交（与Alice的工作同时进行）。由于它们始于Alice修改后的代码库，因此保留了Alice的更改。
完全放弃当前合并（MB），保留他与爱丽丝并行的一系列提交，但最后没有合并提交。
在这里，Bob将他的一系列提交与Alice的合并结果合并。由于合并结果中已合并了她的代码，因此，除非鲍勃出于某种原因将其删除，否则鲍勃的合并结果中也会合并了爱丽丝的代码。
与Alice的合并合并。
在这里，鲍勃保留了MB（来自链接的“问答”），但添加了一个 new 合并，该合并将MB与MA合并。这将Alice的更改与Bob的更改结合在一起，因此将Alice的工作纳入了最终结果。
这三个选项之间的区别在于最终的图形和提交集：读取这些内容（提交和图形，两者）有多难，将来将其用于零值有多难。任何引入的错误，等等。这三个过程都有参数，而这三个过程都有参数。 Alice和Bob应该同意他们使用的任何程序，但是该协议不是Git提供的工具的一部分。