高效的TFS分支策略建议

Question

我们公司（内部项目）使用版本控制（TFS，现在是2015）来简单地保留已发布代码的审计跟踪 - 我已经引入了分支和合并的使用，它完全改变了我们看待瓶颈的方式开发渠道一般都很受欢迎，但现在我正在寻找下一步。

我们的代码包含一大块软件和其他几个附带的业务应用程序。

我们有四个环境，我们始终跟上，我们的管道＆＃39;是这样的。

• 开发人员在本地工作。
• 将代码推送到＆＃39;开发＆＃39;环境（所以我们都可以查看代码，看看它在环境e.t.c中的集成程度）
• 当测试准备就绪时，我们推动测试＆＃39; - 这是已被批准在管道上移动的代码，因此是 环境比“开发”更加稳定。
• 接下来，我们将它传递给UAT服务器，该服务器本质上是对实时服务器的模仿，以便像现场版本一样稳定和代表 尽可能。已批准移动到此处的代码并不常见。
• 最后，生产环境。

现在我简单地采用了为每个环境设置分支的方法，允许轻松比较，让人们快速获取源和诸如此类的东西，并看到代码库在链中的进展。

主要 - ＆gt;阶段 - ＆gt;测试 - ＆gt; DEV

这是一条单线性线，我们可以简单地查看MAIN分支的历史记录，以查看所有不同的已发布版本。

从dev分支我们分裂到我们的本地分支，任何修补程序直接来自UAT分支。

这对我们有用 - 但它在程序性程序可行的意义上起作用 - 它可能不是最有效的方法。 我很好奇是否有更好的方法来做到这一点，并且在网上阅读了大量内容后，我觉得人们不会因为环境而拆分他们的分支，但我真的不明白哪个效果更好？尽管合并四次以释放一些代码是一件痛苦的事（尽管大多数时候它是一个相当缓慢的管道，但我们每周发布一次）。

任何帮助都非常感激。

Answer 1

我认为，如上所述，为每个环境维护不同的分支会带来很多开销（特别是合并的数量）。最简单的分支策略如下所示（类似于我们使用的）：

               Main
             |     |
             |     |
            DEV  Release

开发将在DEV分支中发生，一旦为UAT做好准备，我们将其合并到MAIN中，然后创建一个Release分支。此时您可以使用DEV分支进行下一个版本开发，并且当前版本的所有错误修复现在都将在发布分支中进行。 Release分支也将用于PROD部署。

至于这对您是否有用将取决于您的具体需求，但我合作的项目中有80％使用上述分支策略。

Answer 2

如果提到分支策略越复杂，维护的开销就越大，这是正确的。

但如果情况要求没有逃脱。如果您没有阅读ALM游侠为TFS撰写的branching strategy文档，请查看。它应该对你有帮助。

我认为您所遵循的策略不是线性分支，而是下图中的分支。 在更复杂的企业软件中，分支策略归结为此。