branch - 用于频繁发布和无限期维护的 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
并已获准交货)

克制创造新事物
分支机构。绝对需要时应创建新分支。
原因可能是:大版本、功能隔离、发布客户
版本、修补程序\补丁隔离

尽可能使用标签而不是新分支。将功能合并到主干分支后，对其进行标记并禁止进一步 checkin
分公司

根据经验，只有积极开发的分支
on 应该在线。通过删除避免“僵尸”分支
已合并且不活动的分支

频繁合并

使用CI nightly builds作为质量控制的第一线

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