2

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

这是我的情况的图表: 棘手的情况

图形显示如下:我从主干创建了一个分支 (feature_phase_1),并在该分支上工作,直到我对我的工作感到满意。然后,由于我们必须在代码返回主干之前对其进行审查,并且由于我需要 feature_phase_1 中的代码才能继续工作,所以我从第一个分支 (feature_phase_1) 创建了一个新分支 (feature_phase_2)。我一直在那个分支上工作,直到在第一个分支上完成代码审查,将我的更改提交到 feature_phase_2,切换到 feature_phase_1,进行请求的更改,提交到分支,然后重新集成合并到主干。

然后我就头疼了。

由于建议不要继续在已重新集成的分支上工作,我想我会用我的两个分支之间的差异制作一个补丁并将其应用到一个新分支(从主干,在重新集成我的 feature_phase_1 分支后) ,并删除当前的 feature_phase_2。但它给了我更多的冲突,超出了我的预期。

我在某处读到也不建议从分支创建分支。我现在明白为什么了,因为我不知道如何处理里面的东西。我设法应用补丁和编辑冲突,但它很混乱,而且在这个过程中有些东西滑倒了。

对于这种情况,建议的方法是什么,可以最大限度地减少冲突风险和手动处理合并过程?这是我看到的:

  • 从主干而不是从分支创建一个 feature_phase_2,将 feature_phase_1 的更改合并到 feature_phase_2,然后随着事情的发展继续从主干合并(我预计在重新集成 feature_phase_1 后会发生冲突)。例子
  • 继续使用 feature_phase_2 并在重新集成 feature_phase_1 后从主干合并,然后将 feature_phase_2 重新集成到主干(有点像这里描述的内容)。这种技术在我看来有点不干净,因为你必须从一个分支分支,然后重新整合两个级别
  • ??

谢谢

4

1 回答 1

1

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

将 feature_phase_1 合并到 feature_phase_2 而不是将主干合并到 phase_2 (phase_1-239 将是 phase_2-241 而不是 trunk-240 的父级),然后将 phase_2 合并到主干

于 2013-01-08T20:02:57.703 回答