使用“合并修订范围”从分支合并到主干

我已经像这样在 Subversion/TortoiseSVN 中合并了几次：

方法一：

• 1）我更改主干并提交。

• 2）我在分支中进行其他更改并提交。

• 3）在主干的工作副本中： 我使用 TortoiseSVN 从分支合并 “合并一系列修订”。

• 4）然后我提交主干并删除分支。

但是，那TortoiseSVN-手册 http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html建议采用以下方法代替 3) 和 4)：

方法B：

• 3*) 在来自分支的工作副本中： 使用 TortoiseSVN 的“合并一系列修订”合并来自主干的更改。

• 4*) 提交分支，包括主干更改。

• 5*) 在主干的工作副本中： 使用 TortoiseSVN 的“重新集成分支”合并分支中的更改。

• 6*) 提交主干并删除分支。

我发现 A 更容易，并且没有找到为什么我不应该这样做的原因。

方法 B 或 A 的论据是什么， 当从分支合并回主干时？

这就是所谓的“rebasing” 在合并回来之前：在将本地分支合并回主干之前，您可以使用主干演变“重新调整”（或更新）本地分支。

它允许分辨率慢合并的within你的“一个分支”，可能有中间提交。
然后，当一切完成后，您可以进行简单的合并回到主干。
这样，您不必仅仅因为在主干上进行合并而延迟提交（因为主干上只允许稳定的提交）。

您认为使用方法“A”有害吗？

不，如果合并是一个微不足道的合并，并且结果可预测。在这种情况下，方法 B 会浪费时间，不需要额外的合并（并且您应该始终寻求尽可能少的合并：每个操作都可能容易出错）

但是，如果结果没有提前很好地定义，那么绝对建议使用方法“B”，它允许您在影响“主干”之前探索自己分支中的合并结果。

两种方法都是有用的，不应寻求仅应用一种或仅应用另一种，而应选择最适合当前情况的一种。