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

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

我已经对此做了重要的研究，并发现“发布分支”是有意义的。然而，我们之前已经实现了这个功能，并且发现它会带来巨大的开销，因为我们每两周发布一次

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

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

在每次签入时，代码都被搁置起来进行代码分析、成功构建和代码审查，然后才被包括在主干分支中

---

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

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

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

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

可以使用连续集成实现自动化，例如，如果合并产生冲突，每晚安排一次失败的合并。这将避免在最后将分支折叠回主干时出现严重的合并