git：合并两个分支：什么方向？

Question

我们有以下情况：

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

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

我现在想要的是一个新的分支，我将 iphone 和当前的 master 合并在一起。并且在稍后的某个时间，这应该被合并到 master 中。

首先，我打算这样做：

git checkout iphone -b iphone31
git merge master

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

git checkout master -b iphone31
git merge iphone

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

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

也许甚至从 master 开始并将 iphone 的每个提交合并到它会更容易？喜欢这样做：

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

---

最后，当这个合并完成时（即所有冲突都已解决并且它正在工作），我想这样做：

git checkout master
git merge iphone31

Answer 1

最好的方法实际上取决于其他人是否拥有您的代码的远程副本。如果 master 分支仅在您的本地机器上，您可以使用 rebase 命令以交互方式将功能分支中的提交应用到 master：

git checkout master -b iphone-merge-branch
git rebase -i iphone

请注意，这会改变您的新 iphone-merge-branch 分支的提交历史记录，这可能会给其他人稍后试图将您的更改拉入他们的结帐时出现问题。相比之下，merge 命令将更改应用为新的提交，这在协作时更安全，因为它不会影响分支历史记录。有关使用 rebase 的一些有用提示，请参阅 this article。

如果您需要保持提交历史同步，最好执行合并。您可以使用 git mergetool 使用可视化差异工具以交互方式逐个修复冲突（有关此的教程可以是 found here）：

git checkout master -b iphone-merge-branch
git merge iphone
git mergetool -t kdiff3

第三个选项，如果你想绝对控制这个过程，那就是使用 git cherry-pick。您可以使用 gitk（或您最喜欢的历史查看器）查看 iphone 分支中的提交哈希，记下它们，然后将它们单独挑选到合并分支中 - 随时修复冲突。这个过程的解释可以是found here。此过程将是最慢的，但如果其他方法不起作用，则可能是最好的后备选项：

gitk iphone
<note down the 35 commit SHA hashes in this branch>
git checkout master -b iphone-merge-branch
git cherry-pick b50788b
git cherry-pick g614590
...

Answer 2

你说：

iphone 分支与 master 相比已经很老了

你真的想将它们合并成一个新的分支吗？

master 和 iphone 分支的目的现在会非常不同（因为 iphone 已经很老了）。一个新的分支将 iphone 与 主人的祖先合并会更好吗？想一想。

我强烈建议您阅读Fun with merges and purposes of branches。

读完那篇文章后，如果你仍然想合并 iphone 和 master，那么 @seanhodges 会解释如何很好地处理冲突。

Answer 3

关于替代品

git checkout iphone -b iphone31
git merge master

和

git checkout master -b iphone31
git merge iphone

他们会有相同的轻松或困难，就像争论一个杯子是半满的还是半空的。

版本树感知

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

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

假设我们要从 Y 签出一个新版本 Z 基于从 C 到 E 的更改，但不包括从 A 到 C。

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

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

现在事情开始看起来很有希望了。注意我没有 在这里改变了任何关系，箭头都指向相同的方向 在上图中和版本 A 仍然是共同的基础。 只改变了布局。

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

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

任务就是正常合并版本 E。

所以你可以合并任何你想要的东西，唯一影响 难易度是在 您选择作为起点或共同基础以及合并到的位置。 您不仅限于使用您的自然起点 版本控制工具建议。

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

回答

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

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

提示：

在纸上画出版本树并用箭头记下你想要的 合并。如果您拆分流程，请在完成时划掉 在几个步骤中。这将使您更清楚地了解您想要什么 去实现，你到目前为止做了什么，还剩下什么。

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

Answer 4

您可能希望在实验之前对您的工作进行本地备份，以便在您不了解发生的情况时重新启动。

如果您想保留它以供参考，请为您的工作创建一个备份分支，以免在 rebase 期间丢失它。

git checkout iphone -b iphone_backup

从master创建一个新分支

git checkout master -b iphone31

然后在它之上重新设置基准。

git rebase -i --onto iphone31 iphone

上面的 Sean 关于 rebase 一次应用一个提交是正确的。但是不要担心你变基到的分支上的现有提交——它们不会被改变。 Rebase 将新的（适应的）提交放在它们之上。一次完成一个提交时，您可以更好地控制冲突。但重要的是，您必须将工作重新建立在 master 之上，而不是反过来，这样 master 的历史就不会改变。

或者，你只能这样做

git rebase -i master iphone

如果您不关心备份 iphone 分支。查看 rebase 文档以获取详细信息和替代方案http://git-scm.com/docs/git-rebase。

Answer 5

有区别。

---

在合并期间始终检查目标分支（即，如果将 A 合并到 B，则检查 B）。

---

人们常说合并方向无所谓，但这是错误的。尽管无论合并方向如何，生成的内容都是相同的，但有几个方面是不同的：

1. 最终的合并提交中列出的差异会因方向而异。
2. 大多数分支可视化工具将使用合并方向来决定哪个分支是“主要”分支。

详细来说，想象一下这个夸张的例子：

• 您在 1000 次提交后从 MASTER 分支出来，并将其命名为 DEVELOP（或者在跟踪分支场景中，您已经有一段时间没有获取数据了）。
• 您将一个提交添加到 DEVELOP。您知道此更改没有冲突。
• 您想将更改推送到 MASTER。
• 您错误地将 MASTER 合并到 DEVELOP（即 DEVELOP 在合并期间被签出）。然后，您将 DEVELOP 作为新的 MASTER 推送。
• 生成的合并提交中的差异将显示 MASTER 中发生的所有 1000 次提交，因为 DEVELOP 是参考点。

这些数据不仅毫无用处，而且很难了解正在发生的事情。大多数可视化工具会让您的 DEVELOP 行看起来一直是主要的，其中包含 1000 个提交。

我的建议是：在合并期间始终检查目标分支（即，如果将 A 合并到 B，则检查 B）。

• 如果您正在处理并行分支并希望定期从主分支引入更改，请检查您的并行分支。差异是有意义的——您将看到在主分支中对您的分支所做的更改。
• 当您完成并行工作并希望将更改合并到主分支中时，请检查主分支并与并行分支合并。差异再次有意义 - 它会显示您对主分支的并行更改。

在我看来，日志的可读性很重要。