我正在研究谷歌的trunk based development
在基于主干的开发中，开发人员将代码直接推送到主干中。在发布分支中所做的更改（准备发布时的代码快照）通常会尽快合并回主干（由向下箭头表示）。在这种方法中，在某些情况下，必须挑选错误修复并将其合并到版本中（如向上箭头所示），但这些情况不像在主干中开发新功能那样频繁。
说明
在发布分支中所做的更改（准备发布时的代码快照）通常会尽快合并回主干（由向下箭头表示）
我很困惑，因为在此之前它声明开发人员将代码直接推送到主干。
如果应该将代码直接推送到主干，代码将如何推送到发布分支？
为什么会挑选错误修复并将其合并到发布分支中，这暗示错误修复在发布分支中完成，并且发布分支合并到主分支？
假设代码没有直接推送到发布分支，如果发布分支是从master分支出来的，为什么还要合并回master/trunk？
【问题讨论】：
- 如果应该将代码直接推送到主干，代码将如何推送到发布分支？
发布分支的目标是让您专注于准备要发布的软件，而不必担心 trunk 中发生的事情。当团队的其他成员通过直接提交到 trunk 来继续致力于下一个版本时，您稳定通过修复 release 分支中的任何剩余错误来稳定选择发布的快照。 p>
在此稳定过程中，您可能会发现trunk 中也存在的错误。发生这种情况时，您需要合并 release 分支回到 trunk 以集成这些错误修复。
- 为什么会挑选错误修复并将其合并到发布分支中，这暗示错误修复在发布分支中完成，并且发布分支合并到主分支？
当您致力于稳定release 分支中的软件时，团队的其他成员可能会在trunk 中发现同样存在于release 中的错误。如果发生这种情况，您需要将错误修复集成到版本中 - 但是，您不能将 trunk 合并到 release，因为这会带来团队一直在努力的所有新内容。正在准备发布。所以，相反，您cherry-pick 只是修复错误的提交，仅此而已。
- 假设代码没有直接推送到发布分支，如果发布分支是从 master 分叉的，为什么还要合并回 master/trunk？
请参阅答案 1。请注意，如果主干中的代码与最初为发布选择的代码相差太远，则将发布分支合并回主干可能会导致大量合并冲突。例如，您可能修复了 release 中的一个错误，但由于重构，修改后的文件不再位于 trunk 中。
还值得一提的是，发布分支并不总是值得额外的开销。你链接到offers an example的文档：
在一天发生多次发布的情况下，根本不需要发布分支，因为更改可以直接推送到 master 并从那里部署。
trunk-based development 的目标是通过将必须维护的分支数量减少到一个来简化软件开发过程。
【讨论】：