合并功能分支以释放分支而不是主干

Question

我对两个具有功能分支和发布分支的源代码控制方案有疑问：

• 在方案1中，功能分支合并到了主干。
• 在方案2中，功能分支合并到最新版本的分支。

与方案1相比，方案2的后果是什么？

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

---

两种情况的更多详细信息：

• 所有开发都在功能分支中完成
• 分支总是从主干完成的

场景1（类似于此SO-answer中描述的场景）：

• 功能分支始终合并到主干
• 开始准备新版本时 ，将从主干中创建一个新的版本分支
• 从发布分支进行质量检查和部署后，发布分支中的更改/错误修正将合并到主干和较新的发布分支中
• 对主干的更改将合并到所有功能分支

方案2：

• 功能分支始终合并到最新版本的分支
• 当当前发行分支不再接受新功能并且开始准备最终发行时，会从主干创建一个新的发行分支
• 从发布分支进行质量检查和部署后，发布分支中的更改/错误修正将合并到主干
• 对主干所做的更改将合并到所有功能分支和最新发布的分支中

Answer 1

由于分支完全是关于隔离的 （请参阅“ 何时分支” ），因此两种方案之间的区别是希望主分支trunk具有以下角色 ：

• 方案2更适合静态角色 ： trunk将表示生产中的产品（偶尔需要将修补程序合并回当前功能和下一发行版分支）

• 场景1更适合于动态角色 ： trunk是各种功能的集成，从那里创建了发布分支以合并功能，这些功能实际上将成为下一版本的一部分。