SVN分支和子分支技术

时间:2013-01-08 18:43:18

标签: svn branching-and-merging

我们最近在我工作的地方引入了功能分支(使用SVN)的概念,我偶然发现了一个我不确定如何处理它的情况。

以下是我的情况图: sticky situation

这是图形所说的内容:我从主干创建了一个分支(feature_phase_1)并在该分支上工作,直到我对我的工作感到满意为止。然后,因为我们必须在回到主干之前检查我们的代码,并且因为我需要feature_phase_1中的代码继续工作,所以我从第一个分支(feature_phase_1)创建了一个新的分支(feature_phase_2)。我在该分支上工作,直到在第一个分支上完成代码审查,将我的更改提交到feature_phase_2,切换到feature_phase_1,进行所请求的更改,提交到分支,然后重新集成合并到主干。

然后我头疼了。

由于建议不要继续处理已经重新整合的分支,我想我会用我的两个分支之间的差异做一个补丁并将它应用到一个新的分支(从主干,重新整合后我的feature_phase_1 branch),并删除当前feature_phase_2。但它给了我更多的冲突,而不是我的预期。

我在某地读到也没有建议从分支创建分支。我现在可以看到为什么,因为我不知道如何处理那里的东西。我设法应用了修补程序并编辑了冲突,但它很混乱,而且过程中的东西都滑了。

这种情况的建议方法是什么,可以最大程度地降低冲突和手动处理合并过程的风险?以下是我看到的内容:

  • 从主干而不是从分支创建feature_phase_2,将feature_phase_1中的更改​​合并到feature_phase_2中,然后继续合并主干(我会在重新集成feature_phase_1后发生冲突)。example
  • 继续使用feature_phase_2并在重新集成feature_phase_1后从主干合并,然后将feature_phase_2重新集成到主干(有点像所描述的here)。这种技术在我看来有点不干净,因为你必须从一个分支分支,然后重新集成两个级别
  • ...

由于

1 个答案:

答案 0 :(得分:1)

为你的照片。 1(原始工作流程)更好(我猜)选择可以是:

将feature_phase_1合并到feature_phase_2而不是将trunk合并到phase_2(phase_1-239将是phase_2-241的父级而不是trunk-240)并且将phase_2合并到trunk