Microsoft ALM团队将基本分支计划描述为需要 MAIN ， DEV 和 RELEASE 分支 .
我正在努力将分支/合并介绍给目前使用源代码控制而没有任何分支的新团队 .
我想知道如何实际使用RELEASE分支 .
可以在DEV分支中进行更改然后合并到MAIN分支而无需RELEASE分支吗？ MAIN仍然是只读的 . 它本质上基本上是RELEASE分支 . 我说这个的原因是因为我们没有那么多变化，但我想将稳定代码与新变化隔离开来 . 我们的概念"release"每个人的说法尚未明确定义 . 我还在努力 .
我只是不知道我的团队 needs 是一个RELEASE分支（具体考虑我们的需求） .
我很感激有关只有 MAIN 和 DEV 分支的策略的一些评论 .
2 回答
通常，释放分支用于“保管” . 基本上与标签相同 .
发布到 生产环境 通常是非常重要的事件，并且您想要确切地知道您发布的源（如果您需要返回它） . 当人们习惯于创建标签来跟踪这一点时，回过头来创建Release分支更好，原因如下：
标签在TFS中是可变的，这意味着有人可以更改标签，并且不会有审计跟踪
分支当然也是可变的（可以检入更改），但这可以通过分支特定权限锁定
此外，如果对Release分支进行了更改（它永远不应该），那么至少您有一个历史记录的审计跟踪
尽管分支看起来像是一个重量级的操作，创建了整个代码库的副本，但实际上TFS只是创建了一个指向相同文件的新指针，因此存储成本微不足道
当我在客户端（替换SVN）实现TFS时，我走了另一条路 . 我所做的是最初引入MAIN分支和RELEASE分支而不是DEV分支，因为这对团队来说似乎很混乱 . 最初，很难将DEV分支的目的传达给SVN熟悉的团队 .
我们RELEASE分支的主要目的是保留一个历史占位符，如另一个答案所述 . 目前我们正在使用Git，我们有一个CI服务器执行发布过程，分支发布/ $ version_number . 我认为这个概念可能更容易理解并传达给您的团队 . 即实际发布时自动创建发布分支 .