tfs - 版本控制分支策略 - 中型团队和频繁发布

Question

我们是一个由 10 名开发人员(每个项目 3 名开发人员)组成的中型团队，想知道哪种版本控制策略是最佳的。

已经对此进行了大量研究，发现“发布时的分支” 很有意义。但是，我们之前实现过此方法并发现它带来了很大的开销，因为我们每两周发布一次。

一种很少提及的模式是使用标签按需分支。它的工作方式是在每个要测试和发布的版本上标记代码并拍摄快照。然后只有在生产中存在需要修复的错误时才分支。

我绘制了一个图表来说明这种方法，它还为跨越多个冲刺的功能合并了功能分支。

每次 checkin 时，代码都会被搁置，进行代码分析、构建成功和代码审查，然后才会被纳入主干分支。

是否有任何我不知道的缺点？为什么这种方法没有得到更广泛的应用？

Answer 1

我不知道这种方法有任何重大问题。

我建议定期从主干到分支进行合并，以防止它们与主干代码偏离太远。这对于长期存在的分支尤为重要。

可以使用持续集成来自动执行此操作，例如每晚安排一次合并，如果合并产生冲突，则合并失败。当您将分支折叠回主干时，这将避免最后出现令人讨厌的合并。