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

Question

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

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

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

我已经绘制了一个图表来说明这种方法，它还结合了跨多个 sprint 的特性的分支特性。

在每次签入时，将代码搁置以进行代码分析、构建成功和代码审查，然后再将其包含在主干分支中。

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

Answer 1

我不知道这种方法有什么重大问题。

我建议定期从主干合并到分支，以防止它们偏离主干代码太远。这对于长寿命的分支尤其重要。

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

Answer 2

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