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显然是我们的开发分支,预计不会稳定.通过同行评审的开发者更改被提升到主干,我认为这是稳定但仍然是开发代码.当我们向主干添加新功能时(通常是响应客户项目),我们最终接近发布,然后我将主干分支到上面的"Product ABC 2.0"这样的分支中.

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

这似乎是一个错综复杂的分支计划,我确信这是完全错误的,或者没有好的方法来分支我们的模型以及我们为不同的客户做了多少版本和维护多年.

MS指南(甚至是高级高级计划)似乎基于更简单的发布方案.这里有什么我想念的东西可以带回一些理智吗？

Answer 1

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

力求尽可能简单的分支计划

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

需要考虑的要点：

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

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