高效的TFS分支策略建议-Java 学习之路

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

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

我们有四个环境，我们始终跟上，我们的“管道”就是这样 .

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

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

MAIN - > STAGE - > TEST - > DEV

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

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

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

任何帮助非常感谢 .

2 回答

2
我认为，正如您在上面正确提到的那样为每个环境维护不同的分支（特别是合并的数量），这是一个很大的开销 . 最简单的分支策略如下所示（类似于我们使用的）：
```
Main
             |     |
             |     |
            DEV  Release
```
开发将在DEV分支中进行，一旦为UAT做好准备，我们将其合并到MAIN中，然后创建Release分支 . 此时您可以使用DEV分支进行下一个版本开发，并且当前版本的所有错误修复现在都将在发布分支中进行 . Release分支也将用于PROD部署 .

至于这对你是否有用将取决于你的具体需求，但我合作的项目中有80％使用上述分支策略 .
回复于 2024-05-06T05:19:38+08:00
2

当提到分支策略越复杂时，维护的开销就越大，这是正确的 .

但如果情况要求没有逃脱 . 如果您没有通过ALM护林员为TFS完成branching strategy文件，请查看 . 它应该对你有所帮助 .

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

回复于 2024-05-06T05:19:38+08:00

高效的TFS分支策略建议

2 回答

相关问题