合并功能分支以发布分支而不是主干

Question

我有一个关于两个源代码控制方案的问题，包括功能分支和发布分支：

• 在场景 1 中，功能分支合并到主干。
• 在场景 2 中，功能分支合并到最新版本分支。

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

这两种方案可能的优点和缺点是什么？

---

两个场景的更多细节：

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

场景一（类似于this SO-answer中的描述）：

• 功能分支总是合并到主干
• 从主干创建一个新的发布分支，当新发布的准备工作开始时
• 在发布分支进行 QA 和部署后，发布分支中的更改/错误修复将合并到 主干和更新的发布分支
• 对主干的更改合并到所有功能分支

场景 2：

• 功能分支总是合并到最新发布的分支
• 从主干创建一个新的发布分支，当当前发布分支不再接受新功能并开始为最终发布做准备时
• 在发布分支进行 QA 和部署后，发布分支中的更改/错误修复合并到 trunk
• 对主干的更改合并到所有功能分支和最新发布分支

Answer 1

由于分支完全是关于隔离（请参阅“When should you branch”），这两种情况之间的区别是您希望主分支trunk 具有的角色 ：

• 场景 2 更适合 静态角色：trunk 将代表生产中的内容（偶尔需要合并回当前功能的热修复和下一个发布分支）

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