分支和合并策略

Question

我的任务是在接下来的6个月内提出分支，合并和发布的策略。

复杂性来自于我们将运行多个项目，所有项目都有不同的代码更改和不同的发布日期，但开发日期大致相同。

目前我们正在使用VSS进行代码管理，但是我们知道它可能会导致一些问题，并且会在新开发之前迁移到TFS。

在制定计划之前，我应该采用什么策略以及应该考虑哪些事项？

对不起，如果这个含糊不清，请随时提出问题，如果需要，我会更新更多信息。

Answer 1

这是我遇到过的最好的source control pattern。它强调了使行李箱不受任何垃圾（行李箱中没有垃圾）的重要性。开发应该在开发分支中进行，并且定期合并（在代码测试之后）应该被回到主干（图1），但是该模型还允许在仍在开发中修补源（图2）。我绝对建议完整阅读这篇文章，以便完全理解。

     Pic 1

     Pic 2

编辑：没有文字，图片肯定会让人感到困惑。我可以解释，但我基本上会复制原作者。话虽如此，我可能应该选择更好的图片来描述合并过程，所以希望这会有所帮助。不过，我仍然建议你阅读这篇文章：

Answer 2

我看到分支工作的最简单和最常见的方式是两个前提。主干和发布。我认为这被称为“不稳定主干，稳定分支”的理念。

Trunk 是您的主要来源。它包含“最新和最好的”代码，并且具有前瞻性。它通常并不总是稳定的。

发布是与trunk的一对多关联。有一个主干但很多版本都来自主干。一旦特定功能里程碑被击中，发布通常从主干的分支开始，因此特定部署留下的“唯一”事情应该只是错误修复。然后分支主干，给它一个标签（例如1.6 Release是我们当前的最新版本），构建并发布给QA。我们还在此时推送主干的版本号（通常是次要号码）以确保我们没有两个具有相同号码的版本。

然后在发布分支上开始测试周期。在进行了足够的测试后，您将错误修复应用于发布分支，将这些修复合并回主干（以确保错误修复继续进行！）然后重新发布分支的构建。这个QA循环一直持续到你们都满意为止，最终发布给客户。来自客户的任何错误报告都是准确的（即它们是一个错误！）与相关分支开始另一个QA循环。

在您创建未来版本时，最好还尝试将旧客户迁移到更新的分支机构，以减少可能需要修补错误修复的分支机构数量。

使用此技术，您可以使用您的技术将解决方案部署到需要不同服务级别的各种客户（从最少开始），您可以将现有部署与主干中的“危险”新代码隔离开来，并将最差的合并场景是一个分支。

Answer 3

我的第一个建议是阅读Eric Sink的Source Control HOWTO - 特别是branches和branch merge章节。

我们有3个容器 - DEV，MAIN和RELEASE用于我们的工作。 MAIN包含我们所有“准备发布”的代码，我们倾向于将其视为“基本稳定”。 DEV / Iteration（或DEV / Feature，或DEV / RiskyFeatureThatMightBreakSomeoneElse）是来自MAIN的分支，当迭代/特征准备好通过DEV环境升级时合并。我们还从DEV / Iteration分支和MAIN分支设置了TFS构建。

我们的RELEASE容器包含编号版本（类似于许多Subversion存储库中使用的“tags”容器）。我们每次都只是从MAIN中选择一个分支 - 我想说我们正在“切割”一个RELEASE分支，以表示一旦合并完成就不应该进行大量的活动。

对于VSS-＆gt; TFS - Microsoft支持upgrade path 应该保留您的版本历史记录，但如果您不需要历史记录，我会得到最新版本从VSS获取版本，将其检入TFS并归档VSS存储库。

最后一个提示 - 让您的团队成员熟悉源代码管理。 他们必须了解分支和合并，否则你将无法完成大量的清理工作:)。

祝你好运！

Answer 4

颠覆书描述了some common branching patterns。也许您也可以将这些应用于TFS。