使用“合并修订范围"从分支合并到主干 [英] Merging from branch to trunk with 'Merge range of revisions'

问题描述

我已经在Subversion/TortoiseSVN中合并了几次:

I have merged in Subversion/TortoiseSVN like this a few times:

方法A:

• 1)我更改主干并提交.

• 1) I change the trunk and commit.

2)我在分支中进行其他更改并提交.

2) I make other changes in a branch and commit.

3)在主干的工作副本中: 我使用TortoiseSVN从分支合并 合并一系列修订".

3) In a working copy from trunk: I merge from the branch using TortoiseSVN's 'Merge a range of revisions'.

4)然后，我提交干线并删除分支.

4) Then I commit the trunk and delete the branch.

但是， TortoiseSVN手册建议以下内容代替3)和4) :

However, the TortoiseSVN-manual recommends the following instead of 3) and 4):

方法B:

• 3 *)在分支的工作副本中: 使用TortoiseSVN的合并一系列修订"来合并主干中的更改.

• 3*) In a working copy from the branch: Merge changes from trunk using TortoiseSVN's 'Merge a range of revisions'.

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

4*) Commit the branch including trunk changes.

5 *)在主干的工作副本中: 使用TortoiseSVN的重新集成分支"来合并分支中的更改.

5*) In a working copy from the trunk: Merge changes from the branch using TortoiseSVN's 'Reintegrate a branch'.

6 *)提交中继并删除分支.

6*) Commit the trunk and delete the branch.

我发现A容易得多，却没有找到我不应该那样做的原因.

I find A much easier and have not found a reason why I shouldn't do it like that.

方法B或A的参数是什么， 从分支合并回主干时是什么?

What are the arguments for method B, or A, when merging from a branch back to the trunk?

推荐答案

在合并之前称为" rebasing ":您可以在合并之前用主干演变重新设置"(或更新)本地分支将本地分支返回到主干.

It is call "rebasing" before merging back: you "rebase" (or update) your local branch with trunk evolutions before merging back that local branch to trunk.

它允许在您的分支"内内进行低分辨率合并，并可能进行中间提交.
然后，当所有操作完成后，您可以进行简单的合并回到主干.
这样，您不必仅因为您正在主干上合并而延迟提交(因为仅应在主干上允许稳定的提交).

It allows for slow resolution of the merge within your "a branch", with possible intermediate commits.
Then, when all is done, you can do a trivial merge back to trunk.
That way, you do not have to delay commits only because you are merging on trunk (since only stable commits should be allowed on trunk).

您认为使用方法"A"有害吗?

Would you consider it harmful to use approach 'A'?

否，如果合并是次要的合并，并且结果可预测.在那种情况下，方法B会浪费时间，不需要额外的合并(您应该始终尝试进行尽可能少的合并:每个操作都容易出错)

No, if the merge is a trivial one, with a predictible result. In that case, approach B would be a waste of time, an extra merge which is not needed (and you should always seek to make as few merges as possible: each of those operations can be error-prone)

但是如果结果未事先明确定义，则绝对建议使用方法"B"，并允许您在影响行李箱"之前先在自己的分支中探索合并的结果.

But if the result is not well defined in advance, then approach 'B' is definitively recommended, and allows you to explore the result of the merge in your own branch, before impacting 'trunk'.

这两种方法都是有用的，一种不应只应用一种或另一种，而应最适合当前的情况.

Both approaches are useful, one should not seek to apply only one or only the other, but the one most adapted to the situation at hand.

这篇关于使用“合并修订范围"从分支合并到主干的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！