git: merge 两个分支:什么方向？

Question

我们有以下情况:

             A --- B --- C --- ... --- iphone
           /
  ... --- last-working --- ... --- master

在 last-working 和 iPhone 之间，进行了 32 次提交。在 last-working 和 master 之间，进行了很多的提交。

我现在想要的是一个新的分支，我将 iphone 和当前的 master merge 在一起。稍后，这应该 merge 到主控中。

首先，我打算做:

git checkout iphone -b iphone31
git merge master

但后来我想，如果这样做会更好:

git checkout master -b iphone31
git merge iphone

现在我想知道。 结果会有什么不同？ merge 的行为会有所不同吗？

我已经试过了，正如我所料，我遇到了许多冲突，因为 iphone 与 master 相比真的很旧。现在我想知道 merge 它们的最简单方法。

也许甚至从 master 开始并将每个单独的 iphone 提交 merge 到它会更容易？就像这样做:

git checkout master -b iphone31
git merge A
git merge B
git merge C
...
git merge iphone

---

最后，当 merge 完成时(即所有冲突都已解决并且正在运行)，我想这样做:

git checkout master
git merge iphone31

Answer 1

关于备选方案

git checkout iphone -b iphone31
git merge master

和

git checkout master -b iphone31
git merge iphone

他们会有相同的难易程度，就像争论杯子是半满还是半空。

版本树感知

我们如何看待版本树在某种程度上只是我们的主观看法。假设我们有一个如下所示的版本树:

    A----------+
    |          |
    |          |
   \_/        \_/
    B          X
    |          |
    |          |
   \_/        \_/
    C          Y
    |
    |
   \_/
    D
    |
    |
   \_/
    E

假设我们想要从 Y check out 一个新版本 Z基于从 C 到 E 的变化，但不包括从A 到 C。

“哦，那会很困难，因为没有共同的起点。”好吧，不是真的。如果我们只是将对象放置得稍微不同在这样的图形布局中

      /
    C+---------+
    | \        |
    |          |
   \_/         |
    D          B
    |         / \
    |          |
   \_/         |
    E          A
               |
               |
              \_/
               X
               |
               |
              \_/
               Y

现在事情开始看起来很有希望了。请注意，我没有在这里改变了任何关系，箭头都指向与上图和版本A还是通用基础。只有布局发生了变化。

但现在想象一棵不同的树是微不足道的

    C'---------+
    |          |
    |          |
   \_/        \_/
    D          B'
    |          |
    |          |
   \_/        \_/
    E          A
               |
               |
              \_/
               X
               |
               |
              \_/
               Y

任务只是正常 merge 版本 E。

所以你可以 merge 任何你想要的东西，唯一影响的东西难易程度是两者之间所做更改的总和您选择作为起点或公共(public)基地以及您 merge 到的地方。您不限于使用您的自然起点版本控制工具建议。

对于某些版本控制系统/工具，这可能并不简单，但如果一切都失败了没有什么可以阻止您手动执行此操作检查版本 C 并将文件另存为 file1，检查版本 E 并将文件另存为 file2，检查版本 Y 并将文件另存为 file3，并运行 kdiff3 -o merge_result file1 file2 file3。

回答

现在对于你的具体情况很难说清楚产生最少问题的策略，但是如果有很多变化会产生某种冲突拆分和 merge 较小的部分可能更容易。

我的建议是因为 last-working 和 iphone 之间有 32 次提交，例如，您可以从 master 的分支开始，然后 merge 前 16 个提交。如果结果是太麻烦了，还原并尝试 merge 8 个第一次提交。等等。在最坏的情况下，你最终将 32 个提交中的每一个都一个一个地 merge ，但它可能比必须处理所有在一次 merge 操作中累积冲突(和在这种情况下，您正在使用一个真正不同的代码库)。

提示:

在纸上画一个版本树并用箭头标出你想要的 merge 。如果您拆分流程，请在完成的事情上划掉在几个步骤中。这会让你更清楚地了解你想要什么实现目标，您到目前为止所做的以及剩下的。

我真的可以推荐KDiff3 ，它是一个出色的差异/merge 工具。