TFS 2010分支用于频繁发布和无限期维护

Question

我无法找到一个好的分支策略，可以在我们的环境中轻松合并和跟踪变更集。

发布管理的快速摘要如下：

我们有几种商业产品作为解决方案的一部分。不可改变的外部因素导致我们必须无限期地维护软件的多个版本。发布过于频繁，通常是为了响应增强或缺陷列表以及非常激进的计划。仅修正版本通常是在父版本分支中维护的点版本。具有新功能的版本通常会成为新版本/分支。

源代码控制树如下所示：

- trunk - dev
  - Product ABC
    - ABC 1.0
      -  ABC 1.0.1 (point release same branch)
    - ABC 2.0
  - Product XYZ
    - XYZ 1.0
    - XYZ 2.0

Dev显然是我们的开发分支，预计不会稳定。通过同行评审的开发者更改被提升到主干，我认为这是稳定但仍然是开发代码。当我们向主干添加新功能时（通常是响应客户项目），我们最终接近发布，然后我将主干分支到上面的“Product ABC 2.0”这样的分支。

当我们开始修复发布分支中的缺陷时，噩梦就会发生。我们希望将它们合并回主干，但它应该首先进入dev分支 - 但是由于分支是从主干创建的，所以除非我们对dev进行无根合并，否则这是不可能的。同样，如果我们在dev中进行更改并将它们移动到主干中并希望将它们再次合并到产品分支中，则无法进行无基础合并。

这似乎是一个令人费解的分支计划，我确信它是完全错误的，或者没有好的方法来分支我们的模型以及我们为不同的客户多年来做的和维护多少版本。

MS指南（甚至是高级高级计划）似乎基于更简单的发布方案。这里有什么我想念的东西会带来一些理智吗？

Answer 1

看过很多分支策略后，我的初步建议很简单：

尽可能采用最简单的分支计划

换句话说，没有充分理由不要过于复杂。大多数团队将合并视为一种痛苦，而且他们很难获得这种感觉。

要考虑的要点：

• 一旦发布版本（通过QA，发布分支机构将变为只读） 并且已经绿灯交付）
• 坚持创造新的 分支机构。绝对需要时应创建新分支。 原因可能是：主要版本，功能隔离，发布客户 版本，修补程序\补丁隔离
• 如果可能，请选择标签而不是新分支。将功能合并到主\ trunk分支后，标记它并禁止进一步签入 分支
• 根据经验，只有积极开发的分支 应该在线。通过删除避免“僵尸”分支 已合并且无效的分支
• 经常合并
• 使用CI nightly builds作为质量控制的第一行

您的场景可能介于TFS Branching Guide中的场景＃3（分支和标注）和＃4（多功能团队）之间。但是，复杂的开发计划往往多样化，因此在选择新战略时要做出自己的判断。