合并特性分支以释放分支而不是主干

Question

关于两个源代码管理场景，包括特性分支和发布分支，我有一个问题：

场景1中的

• 特性分支被合并到主干。场景2中的
• 特性分支被合并到最新的发布分支。

与场景1相比，场景2的后果是什么？

这两种情况可能的优缺点是什么？

关于这两种情况的更多细节：

所有的开发都是用特性完成的，branches

• branching总是从主干

完成的。

场景1(类似于this SO-answer中的描述)：

新发布分支总是合并到trunk

• a新发布分支，当准备新的release

• after QA和从发布分支部署时，发布分支中的更改/错误将合并到主干，更新的发布branches

• changes到主干合并到所有功能branches

中。

设想2：

发布分支总是合并到最新版本branch

• a新发布分支中，当当前发布分支不再接受新特性并开始为最终的release

• after QA和发布分支部署做准备时，发布分支中的更改/错误将合并到trunk

• changes到所有功能分支，而最新发布的branch

将合并到所有功能分支。

Answer 1

因为分支都是关于trunk 的(参见“When should you branch”)，所以这两个场景之间的区别是--您希望主分支具有的角色

• 场景2更适合于静态角色：trunk将是生产中的特性的表示(偶尔需要将热点修复合并回当前特性，下一个版本的更适合于动态角色：trunk )，它是针对各种特性的集成，发布分支是从那里生成的，以巩固实际上将成为下一个版本的一部分的特性。