用于频繁发布和无限期维护的 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 显然是我们的开发分支，预计不会稳定。通过同行评审的开发更改被提升到主干，我认为主干是稳定但仍然是开发代码。随着我们向主干添加新功能（通常是为了响应客户项目），我们最终接近发布，我从主干分支到上面的“产品 ABC 2.0”这样的分支。

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

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

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

Answer 1

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

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

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

需要考虑的要点：

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

您的场景可能介于 TFS Branching Guide 中的场景 #3（分支和标签）和 #4（多功能团队）之间。然而，复杂的发展计划往往是多样化的，因此在选择新策略时请自行判断。