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

Question

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

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

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

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

---

两个场景的更多细节：

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

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

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

场景二：

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

Answer 1

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

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

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