时间戳

首页 > 解决方案 > 冲突的 GIT 分支同时合并的结果

git - 冲突的 GIT 分支同时合并的结果

问题描述

在大多数情况下，我的问题在这里得到了充分的询问和回答：Git Merging - 同时合并 2 个分支 会发生什么我很好奇的一小部分是在那种情况下 Bob 的代码会发生什么。在他无法合并他的更改时，因为 Alice 先进入了那里，所以现在他的本地 Master 分支与原始分支不同步，他被迫进行拉取或获取以使他的本地分支恢复正常与原产地/主人。他在本地提交的更改会发生什么？当然，如果他再次从 master 拉取，他的更改现在不是在本地覆盖了吗？

[编辑] 我本可以更好地措辞。我认为我要明确的是，在链接的场景中，两个用户都在处理同一个文件，Bob 对文件的第 2 行进行了更改。Alice 还对她分支中的第 2 行进行了更改。爱丽丝首先得到她的合并。Bob 在本地提交他的所有更改并尝试将他的更改合并到源/主。它失败，因为源/主已更改，因此他被迫再次从源/主拉。一旦他这样做了，他的本地主副本就会包含 Alice 的更改。他现在被迫再次提交以将他的更改提交给他的新本地主人，然后他可以合并回原点/主人。

我理解正确吗？

标签： gitmerge

解决方案

在他无法合并他的更改时，因为 Alice 先进入了那里......

那就是你的问题出问题的地方。他可以合并，因为他还没有 Alice 的合并。他不能成功的——因为爱丽丝打败了他——是git push他与另一个 Git 的合并。

失败后git push，鲍勃必须退后一步逃跑git fetch。现在 Bob 已经（并且必须观察） Alice 的合并。如果 Bob 选择遍历所有内容，他可以在他的存储库中覆盖 Alice 的合并——毕竟 Bob 的存储库是 Bob 的，可以按照 Bob 的意愿去做——但是如果他使用 Git 为共享工作提供的默认机制，他会的：

  • 将他的提交重新设置为在 Alice 的合并之后（在此过程中丢弃他的合并），或者
  • 丢弃他当前的合并（这有点棘手，但 Bob 可以git rebase -i很容易地做到这一点），然后与 Alice 的合并重新合并，或者
  • 最简单的方法：将他的合并与爱丽丝的合并。

所有这三种方法都倾向于自动成功，或者存在冲突，其中 Bob 可能是最有能力找出正确解决方案的人。结果是 Bob 现在git push无需使用--force.

让我们再次考虑所有三种情况：

  1. 基于 Alice 的合并。

    在这里，Bob 选择用新的和改进的 rebased 提交（在 Alice 的工作之后）替换他的旧系列提交（与 Alice 的工作并行）。由于它们从 Alice 修改后的代码库开始，因此它们保留了 Alice 的更改。

  2. 完全丢弃当前的合并 ( MB)，留下他与 Alice 并行的一系列提交，但最后没有合并提交。

    在这里，Bob 将他的一系列提交与 Alice 的合并结果合并。由于她的合并结果包含了她的代码，因此 Bob 的合并结果也包含了 Alice 的代码，除非 Bob 出于某种原因将其删除。

  3. 与 Alice 的合并合并。

    在这里，Bob 保留MB（来自链接的问答），但添加了一个与. 合并的新合并。这将 Alice 的更改与 Bob 的更改结合在一起，因此它将 Alice 的工作纳入其最终结果。MBMA

这三个选项之间的区别在于最终图表和提交集：阅读这些（提交和图表，两者）有多难，将来在任何引入的错误中使用归零有多难， 等等。所有三个过程都有论据，也有反对这三个过程的论据。Alice 和 Bob 应该同意他们使用的任何程序，但该协议不是 Git 提供的工具的一部分。

推荐阅读