在 TFS 中分支以获得年度发布计划？

Question

问题： 根据下面提供的信息创建开发和发布分支的最佳实践是什么？

背景： 我在一个小型开发团队工作（2.25 个前端，2 个后端），我们有每年的发布计划。我们的环境不允许在年中提供补丁或服务包，但每隔一段时间，如果我们的用户环境发生变化，我们就会发布一个“重新编译”的版本，其中包含一些错误修复（在当前稳定版本）。

目前，我们在主线上进行所有开发，然后为代码冻结创建一个分支（到目前为止有 5 个），并进行小错误修复和大部分测试。一旦版本被发送出去进行分层和部署，我们就会将这些错误修复合并回主线，并继续为明年的版本开发新功能。该分支永远保留在我们的存储库中。

TFS 执行分支的方式是在源代码管理中创建一个新的“文件夹”，并且它开始变得有点混乱。

想法： 也许我们这样做的方式是正确的，但感觉再过几年，就会有大量的树枝永远不会被触及……似乎永远不会。也许可以创建一个单独的“稳定版本”行，其中标记了每个新版本，然后如果我们需要返回进行年中发布，则可以从该行中恢复它。

Answer 1

• 尽快将您的环境升级到 2010 - TFS 2010 分支功能更加出色，包括管理。

  尽快将

• 你的想法听起来不错 - 当你有一个发行版本时，你会分支一个发行版本，然后修复它。

  你的想法听起来不错 - 当你有

• 你只需要忍受版本的积累。这是有道理的 - 直到你完全退役一个旧版本（这里“永远”并不真实，我打赌 7-8 年后你会杀死一个旧版本），根本没有其他办法。

Answer 2

我工作过的一些地方会这样处理：

• 开发人员从不直接接触“主”分支，它总是代表生产中的内容
• 单个“维护”分支用于全年的所有更改。
• 年底，在所有更改准备就绪后，适当地标记所有内容，并将维护分支合并回主线。从主线准备并发送了一个新的发布版本。
• 维护分支中正在发生持续的变化。
• 冲洗并根据需要重复。

好处是你只有 2 个分支。这使得一些 SCM 相关任务更容易处理，因为您不必继续处理更改文件夹名称等问题。