SVN分支和子分岔技术

Question

我们最近引入了功能分支（使用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到trunk（有点像here所述），继续从trunk中合并。这个技术在我看来似乎有点不洁，因为你必须从一个分支分支，然后重新整合两个层次。
• ??

感谢

Answer 1

为您的照片。 1（原始工作流程）更好（我猜）可以选择：

将feature_phase_1合并到feature_phase_2中，而不是将trunk合并到phase_2（phase_1-239将是phase_2-241的父代，而不是trunk-240），并且在合并phase_2到主干