我已经在Subversion / TortoiseSVN中合并了几次：
方法A：
1）我改变主干并提交。
2）我在分支中进行其他更改并提交。
3）来自trunk的工作副本： 我使用TortoiseSVN从分支合并 '合并一系列修订'。
4）然后我提交主干并删除分支。
然而， TortoiseSVN-manual建议使用以下代替3）和4）：
方法B：
3 *）在分支机构的工作副本中： 使用TortoiseSVN的“合并一系列修订版”合并来自主干的更改。
4 *）提交分支，包括主干更改。
5 *）来自主干的工作副本： 使用TortoiseSVN的“重新整合分支”合并分支的变化。
6 *）提交主干并删除分支。
我发现A更容易，并且没有找到我不应该这样做的理由。
方法B或A的论据是什么？ 什么时候从分支机构合并到主干？
答案 0 :(得分：11)
在合并之前调用“ rebasing ”：在将本地分支合并到主干之前，您使用主干变换“重新”（或更新）本地分支。
它允许你的“a branch”中的合并的慢速分辨率，并允许中间提交。
然后，当一切都完成后，你可以做一个简单的合并回到主干
这样，你不必仅因为你在trunk上合并而延迟提交（因为在trunk上只允许稳定的提交）。
您认为使用'A'方法有害吗？
不，如果合并是一个微不足道的，具有可预测的结果。在这种情况下，方法B将浪费时间，不需要额外的合并（并且您应该总是寻求尽可能少的合并：每个操作都容易出错）
但如果事先没有很好地定义结果，那么明确建议使用方法'B'，并允许您在影响'trunk'之前在自己的分支中探索合并的结果。
这两种方法都很有用，不应该只设法应用一种方法，也不应该只应用另一种方法，而是最适合当前情况的方法。
答案 1 :(得分：0)
关于合并修订范围与重新整合分支：
遵循方法B导致在分支中有两种提交：
合并回主干时，必须只选择分支特有的更改。这是通过重新整合分支来完成的。
最后使用合并范围的修订会使主干混合使用重复的主干更改和私有分支更改。