在TFS中分支年度发布时间表？

Question

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

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

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

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

思想： 也许我们这样做的方式是正确的，但感觉就像在未来几年会有大量的分支永远不会被触及......似乎永远。也许有可能创建一个单独的“稳定版本”系列，其上标有每个新版本，然后如果我们需要回去做一个年中版本，那么它可以从这一行中恢复。

Answer 1

• 尽快将您的环境升级到2010年 - TFS 2010的分支非常优越，包括管理层。

• 你的想法听起来是正确的 - 当你有一个发布版本时，你就分支出来，然后修复它。

• 您只需要使用累积的版本。这是有道理的 - 直到你完全退休（并且“永远”不是真的在这里，我打赌在7 - 8年后你杀了一个旧版本）没有别的办法。

Answer 2

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

• Devs从不直接触及“main”分支，它总是代表生产中的内容
• 单个“维护”分支用于全年的所有更改。
• 在年底，在所有更改准备就绪后，将所有内容标记为适当的标签并将维护分支合并回主线。从主线准备新的版本构建并发送出去。
• 维护部门正在进行更改。
• 根据需要冲洗并重复。

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