SVN 分支和合并在快速变化的高周转特征环境中

Question

我希望这是有道理的，如果之前已经报道过，我深表歉意。

情况：我们定期发布到生产环境。至少每两周发布一次，但通常一周最多可以发布三个版本。我们有一个由 3xSE、2xWD、3xQA 和技术经理/主管（我）组成的专注团队。团队会根据需求波动，但我们通常会发现 QA 的规模会在接近尾声时急剧增加，以应对延迟的需求/资产或大型回归测试阶段。 6 个通常针对发布日期的标准功能分支和一个兼作发布分支的主干。存在合并和分支开销，但我们已经非常擅长将其归结为美术。因此，只要从某个功能分支合并到主干，我们就会定期从主干合并到功能分支来维护分支。这为我们提供了灵活性，允许我们的客户更改他们的要求、撤回整个版本等，而不会对在单独分支中完成的版本的其他元素产生太大影响。

问题：我想看看改进这个过程的方法，我们已经研究了在主干存储库中完成所有工作的选项，分支到 QA 存储库，然后进入发布分支。如果需要从主干中使用功能分支，我们仍然可以使用，尽管这可能会令人不悦。我的观点是，要将网站的两个主要元素（内容和功能）结合在一起，我们需要让事情依赖于时间。 IE。提供一种将时间依赖于内容的机制（我不确定您是否可以使用该功能）。这个过程的成本会相对较高，如果它不起作用，我们会很快发现，因为我们无法足够快地响应客户。请记住，目前客户可以在各自的 UAT 环境中查看我们的每个功能分支以及主干。

有没有人有任何建议或者之前遇到过类似的情况？

谢谢

Answer 1

您使用的是 SVN 1.5，如果您是，我会认真研究“svn merge --reintegrate”功能。

Answer 2

根据您描述的场景。我建议将实验开发转移到主干，并在冻结发布的功能时创建发布分支。从那时起，只在发布分支中引入错误修复。发布分支可以根据需要保留。发布后无需删除分支。 （当然这样做不会有什么坏处。使用 SVN 不会永久删除任何内容）。