svn - 在 Web 应用程序的开发/维护期间，我应该使用什么分支策略？

Question

我正在尝试为 Web 应用程序项目确定最佳分支策略。这是我到现在为止的想法，我将不胜感激任何评论和经验。

我认为有两种主要的分支策略:“按版本分支”和“按功能分支”。

“按发布分支” : 开发发生在主干上。当发布时间临近时，会为该发布创建一个分支。然后稳定/测试这个分支，最后发布一个版本。发布后，分支会合并回主干，同时保持发布分支处于事件状态以修复错误。是否应用了错误修复，然后将其合并到主干中(如果主干上的开发没有以其他方式掩盖错误)。新功能被添加到主干中，不会影响发布分支。
当新的发布时间临近时，会创建一个新的发布分支。

“按功能分支” :主干始终是“生产”主干(实时代码)。错误修正直接提交到主干。下一个版本的功能在功能分支中开发。错误修复不时合并到功能分支中。当发布时间到来时，特性分支被合并到主干中，生命周期继续。

现在我认为这两种策略之间最大的实际区别是“按发布”允许您维护软件的不同生产版本(当客户端 A 具有版本 1 和客户端 B 版本 1.5 时，客户端是这种情况下的付费客户案件)。相比之下，使用“按功能”策略您只能支持当前的生产版本(所有客户端都使用最新版本)。

由于在典型的 Web 应用程序中，所有客户端都使用相同的“最新”版本(因为它们都访问同一服务器)，因此我认为“按功能”方法是最常用的。它消除了“跨层次结构”合并的需要，比如当一个错误修复必须应用于所有 3 个发布版本时。

所以我目前的状态是我应该“按功能分支”。如果重要的话，我的团队不是很熟练。

Answer 1

如果您在任何时候只有一个发布版本，并且您在一个功能分支中进行所有开发，那么这些方法实际上是相同的。

如果逐个功能对您来说意味着同时有几个分支，我会像瘟疫一样避免它。更多的分支意味着更多的合并，这本身就是一种痛苦，更多的集成 hell 。对单个代码行进行持续集成要好得多。

如果您的部署过程比分支、测试、上线更复杂，那么逐个发布的一个优点是您可以在不同阶段同时运行多个发布分支:一个上线并根据需要进行错误修复，以及另一个正在稳定、测试、通过验收等，同时在主干上继续开发。另一方面，如果您有一个实时主干，一旦您合并一个功能分支以使其生效，您就失去了对当前实时系统进行错误修复的能力。功能分支合并成为一个不归路。