分支策略

我工作的公司开始对他们目前的分支模式产生问题，我想知道社区已经接触到了哪些不同类型的分支策略？

有没有适合不同情况的好方法？你们公司用什么？它们的优点和缺点是什么？

45248 次浏览
小开

我们目前有一个分支用于正在进行的维护，一个分支用于“新计划”，意思是“将来某个时候会出现的东西; 我们不确定什么时候出现。”我们偶尔也有两个维护分支: 一个为当前正在生产的产品提供修复程序，另一个仍然在 QA 中。

我们看到的主要优势是能够更快地响应用户请求和紧急情况。我们可以对正在生产中的分支进行修复，并在不释放任何可能已经签入的额外内容的情况下发布它。

主要的缺点是，我们最终在分支之间进行了大量的合并，这增加了错过或不正确合并某些内容的可能性。到目前为止，这还没有成为一个问题，但这绝对是需要牢记在心的事情。

在我们制定这个策略之前，我们通常在主干中进行所有的开发，只有在发布代码时才进行分支。然后根据需要对该分支进行修复。它更简单，但不那么灵活。

小开

我们在工作中遵循的哲学是保持主干处于一种状态，在这种状态下，您可以在任何时候推动主干，而不会对站点造成严重损害。这并不是说主干总是处于完美状态。里面肯定有虫子。但关键是永远不要让它彻底破碎。

如果要添加特性，请分支。改变设计，树枝。有那么多次我想，“哦，我可以在后备箱里做这个，不会花那么长时间”，然后5个小时后，当我不能找出破坏东西的 bug 时，我真的希望我已经分支了。

当您保持主干干净时，您就有机会快速应用并推出 bug 修复程序。您不必担心那些被您方便地分支的破碎代码。

小开

对于 Subversion，我同意 Ryan Duffield 的评论。他所引用的那一章提供了一个很好的关于使用哪一个系统的分析。

我之所以提出这个问题，是因为 Perforce 提供了一种完全不同的方法来从 SVN 或 CVS 创建分支。另外，所有的 DVCS 都给出了它自己的分支哲学。您的分支策略将由您使用的工具决定。

仅供参考，Svnmerge.py是一个协助合并 SVN 中的分支的工具。只要你经常使用(每10-30次)提交，它就能很好地工作，否则这个工具可能会混淆。

小开

当发布准备好进行最终质量保证时，我们就开始分支。如果在 QA 过程中发现任何问题，那么 bug 将在分支中得到修复、验证，然后合并到主干中。一旦分支通过了 QA，我们就将其标记为一个发布。这个版本的任何修补程序也会被执行到分支上，经过验证，合并到主干上，然后标记为一个单独的版本。

文件夹结构如下所示(1条 QA 线路，2个修复程序版本和主干) :

分行

/REL-1.0

/标签

/REL-1.0

/REL-1.0.1

/REL-1.0.2

后备箱

小开

下面是我过去使用过的成功的方法:

/躯干出血边缘。代码的下一个主要版本。在任何给定的时间可能工作，也可能不工作。

/分行/1.0、1.1等。代码的稳定维护分支。用于修复 bug，稳定新版本。如果是维护分支，它应该编译(如果适用) ，并在任何给定时间准备好 QA/发货。如果是一个稳定分支，它应该编译并完成特性。不应该添加任何新特性，不应该进行重构，也不应该进行代码清理。可以添加前缀来指示稳定分支和维护分支。

/Branch/cool _ Feature/分支/凉爽的特性。用于高度试验性或破坏性的工作，可能会或可能不会使其成为主干(或维修分支)。不能保证代码编译、工作或以其他方式正常运行。在合并到主线分支之前，应该尽可能维持最短的时间。

/tag/1.0.1.1.0.2、1.1.3 a 等。用于标记打包和已发布的版本。从未改变。想做多少标签就做多少，但它们是不可变的。

小开

我们使用野生的，野生的，西方风格的 git 树枝。我们有一些分支具有由约定定义的著名名称，但在我们的例子中，标记实际上对于满足公司流程策略需求更为重要。

我在下面看到您使用 Subversion，所以我认为您可能应该查看 颠覆之书中关于分支的部分。具体来说，请查看 分行维修和 常见分支模式中的“存储库布局”部分。

小开

我们的仓库看起来是这样的:

/trunk
/branches
/sandbox
/vendor
/ccnet

主干 是您的标准，前沿开发。我们使用 CI，因此这必须始终构建并通过测试。

这是我们放置“批准的”大变化的地方，即我们知道的东西将使其成为主干，但可能需要一些工作，并将打破 CI。也是我们从事维护发布工作的地方，它们有自己的 CI 项目。

每个开发人员都有自己的沙箱，外加一个共享的沙箱。这是类似“让我们添加一个 LINQ 提供商到我们的产品”类型的任务，你做的时候，你没有做你的实际工作。它可能最终会进入主干，也可能不会，但它是存在的，并处于版本控制之下。这里没有线人。

标准供应商分支，用于我们编译但不是我们维护的代码的项目。

/ccnet 这是我们的 CI 标签，只有 CI 服务器可以在这里写。后见之明会告诉我们将其重命名为更通用的名称，如 CI、 BUILDS 等。

小开

我在这里没有看到的另一种选择是“变革的分支”哲学。

如果您的主干不是“狂野西部”，而是“当前发布”，那该怎么办？当一次只有一个版本的应用程序发布时(比如一个网站) ，这种方法可以很好地工作。当需要一个新的特性或错误修复时，就会创建一个分支来保存该更改。通常，这允许将修复程序迁移到单独发布，并防止您的牛仔程序员意外地添加您不希望发布的特性。(通常它是一个后门——“仅用于开发/测试”)

本 · 柯林斯的建议对于确定什么样的风格适合你的情况非常有用。

小开
  1. 活动开发的一个分支(/main 或 master，取决于术语)
  2. 每个维护版本都有一个分支-> 它将只接收非常小的修复，而所有主要的开发都转到/main
  3. 每个新任务都有一个分支: 创建一个新分支来处理 Bugzilla/Jira/Rally 上的每个新条目。经常提交，使用 inch pebble 签入来自我记录更改，只有在完成并经过良好测试后才将其合并回其“父”分支。

请看一下这个 http://codicesoftware.blogspot.com/2010/03/branching-strategies.html以获得更好的解释

小开

无论选择哪种分支模式，您都应该尝试将您的分支保持为二叉树形式，如下所示:

   trunk - tags
|
next
/  \  \
bugfix  f1  f2
/   \  \
f11    f21 f22
  • 子节点只应与直接父节点合并。
  • 尽量只将整个分支与父分支合并。永远不要合并分支内的子文件夹。
  • 您可以在需要时进行初选提交，只要您只从整个分支进行合并和选择。
  • 上图中的下一个分支仅用于说明，您可能不需要它。
小开

第一件事: 亲一个(保持简单，愚蠢!)

/branches
/RB-1.0 (*1)
/RB-1.1 (*1)
/RB-2.0 (*1)
/tags
/REL-1.0 (or whatever your version look like e.g. 1.0.0.123 *2)
/REL-1.1
/REL-2.0
/trunk
current development with cool new features ;-)

* 1)保持版本可维护-例如: ServicePack、 Hotfixes、修补程式(如有需要及/或有需要，可能会合并至主干) * 2)大、小、建、修订

经验法则:

  1. 不需要签出 Tags 文件夹
  2. 在发布分支中只有很少的代码(使得合并更简单)——没有代码清理等等。
  3. 永远不要在标签文件夹中编码
  4. 不要将具体的版本信息放入源文件中。使用占位符或0.0.0.0，构建机制将用您正在构建的版本号替换它们
  5. 永远不要将第三方库放入源代码控制中(也没有人会将 STL、 MFC 等库添加到 SVN 中; ——)
  6. 只提交编译的代码
  7. 喜欢使用环境变量而不是硬编码路径(绝对路径和相对路径)

—— hfrmobile

小开

Gnat 为 这次精彩的分解编写了关于分支策略的各种建议。

没有一种分支策略，这种策略是有效的:

  • 你的团队规模
  • 您的产品和生命周期周期
  • 你正在使用的技术(网络，嵌入式，Windows 应用程序)
  • 你的源代码控制，例如 Git，TFS，Hg

Jeff Atwood 的 邮寄分析了很多可能性。另一个要补充的是推广的概念(来自 Ryan Duffield 的链接)。在这个设置中，您有一个 dev 分支、 test 分支和 release 分支。您提升您的代码，直到它到达发布分支并被部署。


提交答案