Google的基于中继的开发-您是否直接将代码推送到分支而不是中继来发布分支？

问题描述

我正在研究Google的trunk based development

在基于主干的开发中，开发人员将代码直接推入主干。在发布分支中所做的更改（即准备发布时的代码快照）通常会尽快合并回主干（由向下箭头表示）。在这种方法中，有些情况下必须选择错误修复程序并将其合并到发行版中（由向上的箭头表示），但是这些情况并不像开发主干中的新功能那样频繁。

它表明

在发布分支中所做的更改（即准备发布时的代码快照）通常会尽快合并回主干（由向下箭头表示）

我很困惑，因为在此之前它声明开发人员将代码直接推入主干。

1. 如果应该将代码直接推送到主干，它将如何被推送到发布分支？

2. 为什么会选择错误修复并合并到发布分支中，这意味着错误修复是在发布分支中完成的，并且该发布分支已合并到母版中？

3. 假设代码没有直接推送到发行分支，那么如果发行分支是从master分支出来的，为什么将release分支合并回master / trunk中？

解决方法

1. 如果应该将代码直接推送到主干，它将如何被推送到发布分支？

发布分支的目标是让您专注于准备发布的软件，而不必担心trunk中发生的事情。当团队的其他成员通过直接提交trunk来努力开发下一个版本时，您可以通过修复release中的所有剩余错误来稳定选定要发布的快照分支。

在此稳定过程中，您可能会发现trunk中也存在错误。发生这种情况时，您需要合并 release分支回到trunk，以集成这些错误修复程序。

1. 为什么会选择错误修复并合并到发布分支中，这意味着错误修复是在发布分支中完成的，并且该发布分支已合并到母版中？

当您在release分支中稳定软件时，团队的其他成员可能会在trunk中发现一个错误，该错误也存在于release中。如果发生这种情况，您将需要在版本中集成错误修复程序-但是，您不能仅将trunk合并到release中，因为这将带来团队一直以来的所有新东西。在准备发行时进行工作。因此，相反，您只需 cherry-pick 即可修复该错误的提交，而仅此而已。

1. 假设代码没有直接推送到发布分支，那么如果发布分支是从master分支出来的，为什么将发布分支合并回master / trunk？

请参见答案1。请注意，如果主干中的代码与最初为该版本选择的代码相距太远，则将发行分支合并回主干可能会导致很多合并冲突。例如，您可能已经修复了release中的一个错误，但是由于重构，已修改的文件不再位于trunk中。

还值得一提的是，发行分支并不总是值得额外的开销。您链接到offers an example的文档：

如果一天多次发布，则根本不需要发布分支，因为可以将更改直接推送到master中并从那里进行部署。

trunk-based development的目标是通过将必须维护的分支数量减少到仅一个，来简化软件开发过程。