SVN 初学者的功能分支

Question

我与一个 PL/SQL 团队合作，该团队习惯于使用 SourceSafe 进行版本控制，该版本控制基于每个文件的锁定。一位用户“拥有”该文件。交付新代码时，有人手动整合所有更改，并将整合包部署在暂存环境中。如果有问题，他们只需从整合包中删除损坏的代码，然后再次暂存。如果一切正常，他们会在生产中部署整合包。

现在他们必须用 Java 编写代码，并使用 SVN。这是一个很大的变化。我们制定了开发和部署策略，但并非 100% 满意。

分支机构：

• trunk：代码稳定并已部署在生产环境中。
• 功能：每个功能都是在从主干创建的特定分支中开发的。
• maintenance：此分支用于修复生产错误，它是在生产部署后从主干创建的。我们只需要处理 N-1 版本。

在部署之前，我们希望在暂存环境中测试新功能和维护错误修复。我们的想法是将要测试的维护和功能分支合并到主干中。在暂存环境中部署主干。

案例 1：新功能需要修正错误

• 修复在功能分支中完成
• 修复后，功能分支会合并到主干中

问：如果该功能由于维护错误修复而无法运行怎么办？功能修复是否应该在主干中完成？

案例 2：新功能尚未投入生产，短期内无法发布

• 由于该功能已合并到主干，我们必须从该分支恢复。

我们是否应该恢复自最新生产版本以来的所有合并，并仅重新合并所需的分支？

案例 3：分期持续 2 周，但仍需要提交 bug 修复生产

• 维护分支已合并到主干。

在暂存期间我们应该在哪个分支上提交错误修复。如果我们将它们提交到维护分支上，我们可能会丢失这些更改，因为当暂存完成时，主干将投入生产，并且将从该主干创建一个新的维护分支。因此，新的维护分支将错过在暂存期间完成的旧维护分支的提交。

如您所见，有很多问题没有答案，而且策略很复杂，需要大量合并（耗时且容易出错）。从我阅读的有关该主题的博客中，我认为我们的分支设置很常见。我们对任何修改持开放态度，目标是制定一个简单易懂的策略。

Answer 1

这似乎过于宽泛和/或过于基于意见，不适合 SO，但是...

案例 1：

如果您不将 MAINT 中的 bigfix 合并回“branches-for-work” - 您完成了分支|合并错误。 IE。对于之前合并到您拥有的主干功能分支（来自我的 POV）：

• 在功能分支中编写错误修复，将新范围（自动检测到不那么古老的 SVN）合并到之前已与维护同步的主干中。 “如果该功能由于维护错误修复而无法工作”，您必须在功能分支中添加新错误修复以“获得维护兼容性”并再次合并

但要小心：SVN 中的循环合并（即使是最新鲜的）可能会在不可预测（马马虎虎）的点上产生奇怪和糟糕的结果，树冲突

是否应该在主干中完成功能修复？

这更多是本地政策的问题，但对于“稳定的主干”，我更喜欢看到只有来自不同分支的合并集的主干（更容易发现历史记录）

案例 2：

在仅合并集（在某种程度上，见下文）主干的情况下，您必须在主干中反向合并单个合并集，将未准备好的生产功能合并到主干。 注意：为了返回特性，你没有重新合并特性分支，你必须反向合并修订，这（反过来）从主干反向合并特性

案例 3

是的，包含修补程序的 MAINT必须合并到 STAGING（主干）中，并像任何其他合并一样重新测试主干