Microsoft ALM团队将基本分支计划描述为需要一个MAIN、DEV和RELEASE分支。
我正在向一个新团队介绍分支/合并，这个团队目前使用的是没有分支的源代码控制。
我想知道RELEASE分支实际上是如何使用的。
是否可以在DEV分支中进行更改，然后合并到MAIN分支而不需要 RELEASE分支?MAIN仍然是只读的。它本质上就是RELEASE分支。我之所以这么说，是因为我们没有那么多的变化，但我想把稳定的代码与新的变化隔离开来。我们的"发布"概念还没有很好地定义。我还在努力。
我只是不知道我的团队是否需要一个RELEASE分支(考虑到我们的需求)。
我希望能得到一些关于仅拥有MAIN和DEV分支的策略的评论。
通常发布分支用于"安全保存"。与标签基本相同。
发布到生产环境通常是一个非常重要的事件，您想要确切地知道您发布了什么源(以防您需要返回它)。当人们习惯于创建标签来跟踪这一点时，但是创建发布分支更好，原因如下:
- 标签在TFS中是可变的，这意味着有人可以更改标签，并且没有审计跟踪
- 分支当然也是可变的(更改可以签入)，但这可以通过分支特定的权限锁定
- 另外，如果对发布分支进行了更改(这永远不应该发生)，至少您可以通过历史记录进行审计跟踪
- 尽管分支看起来像是一个重操作，创建了整个代码库的副本，但实际上TFS只是创建了一个指向相同文件的新指针，因此存储成本是微不足道的
当我在客户机上实现TFS(取代SVN)时，我采用了另一种方式。我所做的是引入一个MAIN分支和一个RELEASE分支，而不是一个DEV分支，因为这对团队来说似乎很困惑。最初也很难将DEV分支的目的传达给熟悉SVN的团队。
我们RELEASE分支的主要目的是保留一个历史占位符，正如在另一个答案中所说的。目前我们使用的是Git，我们有一个CI服务器来执行发布流程和分支release/$version_number。我认为这个概念可能更容易理解并传达给你的团队。例如，在实际发布时自动创建发布分支。