在开发/维护Web应用程序时，我应该使用哪种分支策略？

Question

我正在尝试为Web应用程序项目确定最佳分支策略。以下是我迄今为止所提出的建议，我将非常感谢任何评论和经验。

我看到它的方式有两个主要的分支策略：“按版本分支”和“按功能分支”。

“按发布分支”：开发在主干上进行。当发布时间临近时，将为该发行版创建一个分支。然后稳定/测试该分支，最后进行释放。在发布之后，分支被合并回主干，同时保持发布分支活动以进行错误修复。是否应用了错误修复，然后将其合并到主干中（如果主干上的开发没有以其他方式使错误重叠）。新功能将添加到主干中，不会影响发布分支。 当新的发布时间临近时，将创建一个新的发布分支a.s.o。

“按功能分支”：主干始终是“生产”主干（现场代码）。错误修正直接提交到主干。下一版本的功能是在功能分支中开发的.Bugfixes会不时合并到功能分支中。当发布时间到来时，功能分支将合并到主干中，并且生命周期将继续。

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

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

所以我目前的状态是我应该选择“逐个分支”。如果重要，我的团队不是很熟练。

Answer 1

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

如果你逐个功能意味着马上就有几个分支，我会像瘟疫一样避免它。更多的分支意味着更多的合并，这本身就是一种痛苦，而且更加融合地狱。连续集成到单个代码行要好得多。

如果您的部署过程比分支，测试，上线更具参与性，那么逐个发布的优势在于您可以在不同的阶段同时拥有多个发布分支：一个生存并且被错误修复为必要的，另一个正在稳定，测试，通过验收等，而继续发展在主干上。另一方面，如果你有一个实时主干，一旦你将一个功能分支合并到一个视图中使它生效，你就失去了对当前实时系统进行错误修正的能力。功能分支合并成为不归路。

Answer 2

您正在开发什么样的软件？收缩包装？开源项目？如果是这样，那么请使用“按释放分支”或“不稳定主干”方法。特别是如果你的发布周期是每隔六个月到一年。

但是如果你维持一个基于网络的项目，其频率变化较短，例如每隔几周或更短一次，那么请选择“逐个分支”或“稳定主干”方法。这种方法的问题在于集成了多个功能更改，这些更改具有彻底的更改，使合并过程不那么有趣。这真的很难。

但这两种方法都运作良好，但如果你需要两者呢？也就是说，您有一个项目，每两周进行一次大型功能更改，但您发现有许多错误修复，您不能等待这些功能更改准备就绪。 Trunk是您的发布分支，具有“按功能分支”方法。如果你能获得两个版本并拥有自己的分支怎么办？

通过CollabNet的Bob Archer查看此blog entry。他的敏捷发布策略可以为您提供最佳解决方案。我用过这个。它非常灵活。尽管Bob没有在他的图表中显示它，但您可以同时拥有多个发布分支。这意味着您可以拥有一个已准备好部署到生产阶段的发布分支，以及另一个准备进行最终QA检查的发布分支。但要考虑两件事：

首先，您的开发人员合并有多好？即使它是一个小团队，您也无法自己执行敏捷发布策略方法。每个人都必须尽自己的一份力，他们真的必须了解合并以及他们用来合并的工具。

其次，您需要很好地掌握准备好的变化和即将变化的变化。发布管理是使这项工作像时钟工作的关键。准备好后，每个功能都需要分配给发布分支并合并到它。

无论您选择哪种方法，都取决于您正在开发的内容以及您为该开发发布的更改频率。

Answer 3

这些选择并非相互排斥 - 同时使用两者。 他们解决了不同的问题：

“按版本分支” - 发布分支用于确保您可以在下一个版本处于开发阶段时返回用于生成当前实时版本（或以前发布的版本）的源代码。例如。这是为了更改当前开发主干中的错误修复或回调功能的发布版本。

“按功能分支” - 用于始终保持稳定的开发主干，这对于多个开发人员和实验“可能”功能特别有用。

我会同时使用这两种方法，但如果解决的问题不适用于您，或者您有不同的解决方案，那么您可以放弃其中一种方法。

我强烈建议使用像git或Mercurial这样的现代DVCS。它们适用于并行开发，因此它们存储的变化与旧系统不同，这使得合并更加安全。

Answer 4

存在进一步混淆的风险：您可以让发布分支和对功能分支进行所有更改。这些事情并不是相互排斥的。

话虽这么说，听起来你不需要并行发布系列，你想要经常部署，甚至可能continuously。因此，您可能希望拥有一个可以随时发布的“稳定主干”。功能分支有助于保持中继线稳定，因为只有在完成更改并且已经证明自己时才会合并回主干。

所以我要说你的选择很合适。

Answer 5

我倾向于将Git用于我的项目，但我倾向于遵循的过程就是这样（并且也适用于Subversion）：

• 为每个新功能创建该功能的分支。
• 当一切正常时，将其合并到staging分支，并将其部署到登台服务器（你确实有其中一个，对吗？）
• 一旦我们确定客户端对暂存时的内容感到满意，我们会将暂存分支合并到生产分支中，将其标记为production_release_22或production_release_new_feature_x，然后将该标记部署到生产服务器。

标签从不，永远更新 - 一旦部署了某些内容，它就会保持这种状态，直到构建，测试和标记更多更改 - 然后新标记为部署。通过确保标签部署而不是分支，我让自己（或其他人）不要做“我只是提交一个快速更改并更新服务器没有测试它。“

到目前为止，它对我来说效果很好。