如果之前已经涵盖过，我希望这是有道理和道歉的。
情况：我们定期发布到生产环境。至少每两周一次，但通常一周最多可发布三次。我们拥有一支由3xSE，2xWD，3xQA和技术经理/主管（我）组成的专注团队。团队根据要求而波动，但我们通常会发现质量保证将在最后大幅增加，以应对延迟的需求/资产或大型回归测试阶段。 6个标准功能分支，通常以发布日期为目标，单个主干兼作发布分支。有一个合并和分支的开销，但我们已经变得非常擅长这个艺术。因此，只要从其中一个功能分支合并到主干中，我们就会定期通过从主干到功能分支的合并来维护分支。这为我们提供了灵活性，允许我们的客户改变他们的要求，撤回整个版本等，而不会过多地影响在单独分支中完成的发布的其他元素。
问题：我想看看改进这个过程的方法，我们已经检查了在主干存储库中进行所有工作的选项，分支到QA存储库然后进入发布分支。如果需要，我们仍然可以使用功能分支，尽管这可能是不受欢迎的。我的观点是，为了将网站的两个主要元素，内容和功能结合在一起，我们需要将时间依赖于时间。即提供一种机制来对内容进行时间依赖（我不确定您是否可以使用该功能）。这个过程的成本相对较高，如果它不起作用我们会很快发现，因为我们无法足够快地响应客户端。请记住，目前客户端可以在各自的UAT环境中查看我们的每个功能分支以及主干。
有人有任何建议或遇到类似情况吗？
由于
答案 0 :(得分：2)
您使用的是SVN 1.5，如果您愿意，我会认真研究“svn merge --reintegrate”功能。
答案 1 :(得分：1)
根据您描述的情景。我建议将实验开发移动到主干并在冻结版本的功能时创建发布分支。从那时起，只将错误修复引入发布分支。只要有必要，可以留下发布分支。发布后，无需删除分支。 （当然这样做不会受到伤害。使用SVN永远不会删除任何内容。）