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

Question

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

已经对此做了大量研究，发现“发布时分支”是有道理的。但是，我们之前实现了这一点，并发现它每隔一周发布一次就会产生很大的开销。

几乎没有提到的一种模式是按需分支标签。它的工作方式是在每个要测试和发布的版本上标记并拍摄代码的快照。如果存在需要在生产中修复的错误，则仅进行分支。

我已经绘制了一个图表来说明这种方法，该图还包含了跨多个sprint的功能的分支功能。

在每次办理登机手续时，代码都被搁置以进行代码分析，构建成功并进行代码审查，然后再将其包含在主干分支中。

我不知道有什么缺点吗？为什么这种方法不是更普遍？

Answer 1

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

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

可以使用持续集成来自动执行此操作，例如，如果合并产生冲突，则每晚都会调度合并失败。当你将分支折回到主干时，这将避免最后的讨厌合并。

Answer 2

我认为在TFS中以这种方式使用标签的主要缺点是标签没有版本化。如果一个人删除/更改标签，除非您保留标签的副本/备份，否则无法将其取回。如果您这样做，请保留标签内容的记录，以便在必要时重新创建。