高效的 TFS 分支策略建议

Question

我们公司（内部项目）使用版本控制（TFS，现在是 2015 年）来简单地保留已发布代码的审计跟踪 - 我引入了分支和合并的使用，它彻底改变了我们看待瓶颈的方式开发管道，并且普遍受到好评，但现在我正在寻找下一步。

我们的代码由一个大型软件和其他几个附带的业务应用程序组成。

我们有四个环境始终保持不变，我们的“管道”就是这样。

• 开发人员在本地工作。
• 将代码推送到“开发”环境（这样我们都可以查看代码，看看它在环境中的集成情况等）
• 当测试准备就绪时，我们推送到“测试” - 这是已被批准向上移动的代码，因此 环境比“开发”稳定得多。
• 接下来，我们将它传递给 UAT 服务器，它本质上是对实时服务器的模仿，以保持稳定并代表实时发布 尽可能。获准移至此处的代码并不常见。
• 最后是生产环境。

现在我只是简单地采用了为每个环境设置一个分支的方法，以便于进行比较，以便人们快速获取源代码等，并查看代码库在链上的进展情况。

主要 -> 阶段 -> 测试 -> 开发

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

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

这对我们有用 - 但它在程序程序可以工作的意义上是有效的 - 它可能不是最有效的方法。 我只是很好奇是否有更好的方法可以做到这一点，在网上阅读了大量内容后，我觉得人们不会按环境划分分支，但我真的不明白如何更好地工作？尽管合并四次以发布一些代码很痛苦（尽管大多数时候它是一个相当慢的管道，但我们每周发布一次）。

非常感谢任何帮助。

Answer 1

我认为，正如您在上面正确提到的（尤其是合并的数量），为每个环境维护不同的分支会产生很多开销。最简单的分支策略如下所示（类似于我们使用的）：

               Main
             |     |
             |     |
            DEV  Release

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

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

Answer 2

你说得对，分支策略越复杂，维护的开销就越大。

但是，如果情况需要，也不会逃跑。如果您还没有浏览 ALM rangers 为 TFS 提供的 branching strategy 文档，请查看。它应该对你有帮助。

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