git - 跨 merge 丢失提交之谜

Question

我在 Git merge 时遇到了这个奇怪的问题，我无法解释或分类。是否缺少提交。 merge 出错了吗？它是损坏的数据吗？存储库历史如下所示:

master----\----commit A----cherry-picked changesets from topic---commit B--\----commit C----merge---
           \                                                                \              /
            topic-----------------------------------------------------------merge---------/

现在，我的问题是，当 master 被 merge 到 topic 分支(以使其与提交 A 和 B 保持同步)时，引入了变更集通过提交 B 不存在!如果提交 B 正在修改文件 foo 和 bar，即使 got lot 也不会显示那些文件随着 merge 而改变。文件 foo 和 bar

甚至没有任何冲突

现在，当我将 topic merge 回 master 时，提交 B 实际上被撤销了，没有任何日志或撤销的痕迹!

哪里出了问题？

Answer 1

master----\----commit A----cherry-picked changesets from topic---commit B--\----commit C----merge---
           \                                                                \              /
            topic-----------------------------------------------------------merge---------/
                                                                            ~~~~~
                                                                              ^
                                                                              + here you merged B in topic

主题中已经有一个以提交 B 作为父级的 merge 。因此 B 已完全 merge 到主题中，不会再在任何地方 merge 。

由于您没有主题更改，您显然在 merge 本身或后续提交中恢复了主题。这种逆转是 merge 算法的常规提交，它不会 merge 到 master 中。因此，当您将主题 merge 到主控中时，此提交的更改将被 merge ，恢复提交 B。

要从 B 取回更改，您必须:

• 找到并恢复 B 对主题的更改。
• Cherry-pick B (git cherry-pick B) 主题。
• 重做 merge ， merge 后在新 merge 上重新设置主题基线并忘记原始分支，但由于这涉及倒带，您只能在控制所有具有该分支的存储库的情况下执行此操作。

如何在您没有意识到的情况下更改这些更改？如果您正在 merge 并遇到冲突，您可能会使用“本地”草率地解决它们，认为您在那里还不需要这些更改。但是从 Git(或任何其他版本控制系统；三向 merge 在所有这些系统中的工作方式相同)的角度来看，您已经看到更改并拒绝了它们，因此您永远不会再得到它们，除非您手动重新应用它们。

冲突很可能是由早期的樱桃选择引起的。虽然如果双方看起来相同，算法不会声明冲突，因此如果您选择并 merge ，但如果您在一侧修改精选代码，它会声明冲突。假设你有:

----\-- A -------- B' -- B2 --\
     \                         \
      D -- B -- E -----------merge

B' 选择 B 并且 B2 修改了与 B 相同的代码。在这种情况下， merge 将看到一侧执行了 B，另一侧执行了 B2，因为 cherry-pick 被 B2 stash 并且因此将声明 B 和 B2 之间存在冲突。如果你不仔细查看历史记录，你可能很容易解决这个错误。如果在选择提交时你小心地将目标分支 merge 到源分支中，你可以避免这个问题:

----\-- A --------\- B' -\- B2 --\
     \             \      \       \
      D -- B -- E --m1-----m2----merge

其中 m1 是不涉及 cherry-pick 的正常 merge ，而 m2 是用本地版本解析的，因为它只有远程上的 cherry-picked 更改。这将确保进一步的 merge 能够正常进行。

实际上应该可以为 git 编写 merge 策略来自动执行此操作。