我的任务是制定未来 6 个月的分支、合并和发布策略。
复杂性在于我们将运行多个项目，所有项目都有不同的代码更改和不同的发布日期，但开发开始日期大致相同。
目前我们正在使用 VSS 进行代码管理，但知道它可能会导致一些问题，并且会在新的开发开始之前迁移到 TFS。
在制定计划之前我应该采用哪些策略以及应该考虑哪些事情？
抱歉，如果这含糊不清，请随时提出问题，如果需要，我会更新更多信息。
【问题讨论】：
标签： version-control tfs merge visual-sourcesafe branch
这是我遇到的最好的source control pattern。它强调了让后备箱没有任何垃圾（后备箱中没有垃圾）的重要性。开发应在开发分支中完成，定期合并（在测试代码后）应返回主干（图 1），但该模型还允许在开发过程中修补源代码（图 2）。我绝对建议您完整阅读这篇文章，以完全理解。
图一
图2
编辑：这些图片绝对是没有文字的混乱。我可以解释，但我基本上是在复制原作者。话虽如此，我可能应该选择一张更好的图片来描述合并过程，所以希望这会有所帮助。不过我还是推荐阅读这篇文章：
【讨论】：
我见过的最简单和最常用的分支工作方式是在两个前提下进行。主干和释放。我认为这就是所谓的“不稳定的主干，稳定的分支”理念。
Trunk 是您的主要来源。这包含“最新和最伟大”的代码并且具有前瞻性。它通常并不总是稳定的。
Release 是与主干的一对多关联。有一个主干，但有许多从主干派生的版本。一旦特定功能里程碑被击中，发布通常从主干的一个分支开始，因此对于特定部署剩下的“唯一”事情应该只是错误修复。然后分支主干，给它一个标签（例如 1.6 版本是我们当前的最新版本），构建并将版本发送给 QA。此时，我们还将主干的版本号（通常是次要版本号）向上推，以确保我们没有两个版本号相同。
然后您在发布分支上开始测试周期。当进行了充分的测试后，您将错误修复应用到发布分支，将它们合并回主干（以确保错误修复被继续执行！），然后重新发布分支的构建。这个 QA 循环一直持续到您都满意并且最终将版本提供给客户。来自客户的任何准确的错误报告（即它们是错误！）开始与相关分支的另一个 QA 周期。
在您创建未来的版本时，最好尝试将老客户转移到新的分支上，以减少您可能需要将错误修复补丁修补到其中的潜在分支数量。
使用此技术，您可以将使用您的技术的解决方案部署到需要不同服务级别的各种客户（从至少优先开始），您可以将现有部署与主干中的“危险”新代码和最糟糕的合并隔离开来场景是一个分支。
【讨论】：
我的第一个建议是阅读 Eric Sink 的 Source Control HOWTO - 特别是 branches 和 branch merge 章节。
我们有 3 个容器 - DEV、MAIN 和 RELEASE 用于我们的工作。 MAIN 包含我们所有的“准备发布”代码，我们倾向于认为它是“基本稳定的”。 DEV/Iteration（或 DEV/Feature，或 DEV/RiskyFeatureThatMightBreakSomeoneElse）是 MAIN 的分支，并在 Iteration/Feature 准备好升级到 DEV 环境时合并。我们还从 DEV/Iteration 分支和 MAIN 分支设置了 TFS 构建。
我们的 RELEASE 容器包含编号的版本（类似于许多 Subversion 存储库中使用的“标签”容器）。我们每次都只是从 MAIN 中获取一个分支 - 我想说我们正在“剪切”一个 RELEASE 分支，以表明一旦合并完成，这不应该有很多活动。
至于 VSS->TFS - Microsoft 支持upgrade path，应该保留您的版本历史记录，但如果您不需要历史记录，我会从 VSS 获取最新版本，将其检入 TFS 并存档 VSS 存储库。
最后一个提示 - 让您的团队成员熟悉源代码管理。 他们必须了解分支和合并，否则您将陷入大量清理工作:)。
祝你好运！
【讨论】：
颠覆书描述了some common branching patterns。也许您也可以将这些应用到 TFS。
【讨论】：