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

Question

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

已经对此进行了重大的研究，发现“Branch on release”是有意义的。然而，我们之前实施了这个方案，发现它每两周发布一次就会带来很大的开销。

几乎没有提到的一种模式是使用标签按需分枝。它的工作方式是在每个发行版上标注代码并对其进行快照，以便从中进行测试和发布。然后，只有在生产中需要修复的缺陷时才能进行分支。

我已经绘制了一张图表，说明了这种方法，该方法也将功能上的分支合并到跨多个冲刺。

在每次登记时，代码将被搁置以进行代码分析，在包含在中继分支中之前编译成功并进行代码审查。

有没有什么缺点我不知道？为什么这种方法不会更广泛？

Answer 1

我相信在TFS中以这种方式使用标签的主要缺点是标签没有版本。如果有人删除/更改标签，除非您保留标签的复印/备份，否则无法将其取回。如果你确实遵循这一点，请保留标签内容的记录，以便在必要时重新创建。

Answer 2

我不知道这种方法有任何主要问题。

我建议定期合并从干线到分支，以阻止它们与干线代码分离得太远。这在长期生活的分支上尤为重要。

可以使用持续集成来自动执行此操作，比方说，如果合并造成冲突，则每晚调度一次合并失败。当你将分支折叠回树干时，这将避免最后的讨厌合并。