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

Question

我有一个关于两个源代码控制场景的问题，这两个场景都具有功能分支和发布分支：

• 在场景 1 中，功能分支被合并到主干。
• 在场景 2 中，功能分支被合并到最新的发布分支。

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

这两种情况可能有哪些优点和缺点？

---

两种场景的更多细节：

• 所有开发都在功能分支中完成，
• 分支始终从主干

场景 1 完成（类似于 这个SO-answer）：

• 功能分支始终合并到主干
• 新的发布分支是从主干创建的，当准备开始新版本时，
• 在质​​量保证和从发布分支部署之后，发布分支中的更改/错误修复将合并到主干和更新的版本分支
• 对主干的更改将合并到所有功能分支

场景 2：

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

Answer 1

由于分支都是关于隔离（请参阅“何时应该分支），这两种场景之间的区别在于您希望主干主干具有的角色：

• 场景2更适合 >静态角色：主干将代表生产中的内容（偶尔的修补程序需要合并回当前功能和下一个版本分支）

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