11

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

在我看来，有两种主要的分支策略：“按发布分支”和“按功能分支”。

“发布分支”：开发发生在主干上。当发布时间临近时，会为该发布创建一个分支。然后稳定/测试这个分支，最后发布一个版本。发布后，分支被合并回主干，同时保持发布分支处于活动状态以进行错误修复。是否应用了错误修复，然后将其合并到主干中（如果主干上的开发没有以其他方式使错误黯然失色）。新功能被添加到主干，不会影响发布分支。当新的发布时间临近时，也会创建一个新的发布分支

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

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

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

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

4

5 回答 5

5

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

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

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

于 2010-12-22T14:57:37.300 回答
5

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

但是，如果您维护一个基于 Web 的项目，该项目的更改频率较短，例如每隔几周或更短一次，那么请使用“按功能分支”或“稳定主干”方法。这种方法的问题是集成多个功能更改，这些更改具有全面的更改使合并过程变得不那么有趣。它真的变得很困难。

但是这两个都很好，但是如果你需要两个呢？也就是说，您有一个项目每隔几周部署一次，其中包含较大的功能更改，但是您发现您有许多错误修复，您不能等待这些功能更改准备好。主干是您的发布分支，采用“按功能分支”方法。如果您可以同时获得发布和功能他们自己的分支怎么办？

查看 CollabNet 的 Bob Archer 的这篇博客文章。他的敏捷发布策略让你两全其美。我用过这个。它非常灵活。即使 Bob 没有在他的图表中显示它，您也可以同时拥有多个发布分支。这意味着您可以拥有一个已准备好部署到生产环境的发布分支，而另一个正在为最终的 QA 检查做准备。但有两点需要考虑：

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

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

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

于 2010-12-22T15:12:45.940 回答
2

这些选择不是相互排斥的——两者都使用。 他们解决不同的问题：

“Branch by release” ——发布分支用于确保在下一个版本正在开发中时，您可以返回用于生成当前实时版本（或以前发布的版本）的源。例如，这是为了从当前开发主干中更改发布版本以进行错误修复或回补丁功能。

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

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

我强烈推荐使用现代的 DVCS，比如 git 或 Mercurial。它们面向并行开发，因此它们以不同于旧系统的方式存储更改，这使得合并更加明智。

于 2010-12-22T15:10:09.327 回答
2

冒着让您进一步困惑的风险：您可以拥有发布分支并在功能分支上进行所有更改。这些东西并不相互排斥。

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

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

于 2010-12-22T15:11:46.597 回答
1

我倾向于在我的项目中使用 Git，但我倾向于遵循的过程是这样的（也应该适用于 Subversion）：

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

标签永远不会更新——一旦部署了一些东西，它就会保持这种状态，直到构建、测试和标记更多的更改——然后部署新的标签。通过确保它的标签被部署而不是分支，我让自己（或其他人）不会做诸如“我将提交这个快速更改并更新服务器而不对其进行测试”之类的事情。

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

于 2010-12-22T14:59:57.040 回答