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

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 显然是我们的开发分支，预计不会稳定。通过同行评审的开发更改被提升到主干，我喜欢将其视为稳定但仍在开发的代码。当我们向主干添加新功能时（通常是为了响应客户项目），我们最终接近发布，我从主干分支到一个分支，如上面的“产品 ABC 2.0”。

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

这似乎是一个非常复杂的分支计划，我确信它是完全错误的，或者没有好的方法来使用我们的模型进行分支，以及我们为不同的客户做了和维护了多少个版本。

MS指南（甚至是高级高级计划）似乎是基于更简单的发布场景。我在这里缺少什么可以让我恢复理智的东西吗？

Answer 1

在看过许多分支策略之后，我最初的建议非常简单：

以尽可能简单的分支计划为目标。

换句话说，不要在没有充分理由的情况下使事情变得过于复杂。大多数团队都将合并视为一种痛苦，而这种感觉来之不易。

需要考虑的要点：

• 版本发布后（通过 QA），发布分支将变为只读
  并已获准交付）
• 限制创造新的
  分支机构。绝对需要时应创建新分支。
  原因可能是：主要版本、功能隔离、发布的客户
  版本、修补程序\补丁隔离
• 尽可能使用标签而不是新分支。将功能合并到主\主干分支后，对其进行标记并禁止进一步签入它
  分支
• 根据经验，只有积极开发的分支
  on 应该在线。通过删除来避免“僵尸”分支
  已合并且不活动的分支
• 频繁合并
• 使用 CI nightly builds 作为质量控制的第一线

您的场景可能介于 TFS 分支指南。然而，复杂的发展计划往往是多种多样的，因此在选择新策略时请自行判断。