Git 谷歌'；s基于主干的开发-您是否直接将代码推送到发布分支而不是主干？_Git_Trunk

Git 谷歌'；s基于主干的开发-您是否直接将代码推送到发布分支而不是主干？

git

Git 谷歌'；s基于主干的开发-您是否直接将代码推送到发布分支而不是主干？,git,trunk,Git,Trunk,我正在学习谷歌的在基于主干的开发中，开发人员将代码直接推送到主干中。当代码准备发布时，在发布分支快照中所做的更改通常会尽快合并回主干（向下箭头所示）。在这种方法中，有些情况下，bug修复必须仔细挑选并合并到发行版中（用向上箭头表示），但这些情况不像trunk中开发新特性那样频繁它说当代码准备发布时，在发布分支快照中所做的更改通常会尽快合并回主干（向下箭头所示）我很困惑，因为就在这之前，它声明开发人员将代码直接推送到主干中如果代码应该被直接推送到主干，那么它是如何被推送到发布分支的呢

我正在学习谷歌的

在基于主干的开发中，开发人员将代码直接推送到主干中。当代码准备发布时，在发布分支快照中所做的更改通常会尽快合并回主干（向下箭头所示）。在这种方法中，有些情况下，bug修复必须仔细挑选并合并到发行版中（用向上箭头表示），但这些情况不像trunk中开发新特性那样频繁

它说

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

我很困惑，因为就在这之前，它声明开发人员将代码直接推送到主干中

如果代码应该被直接推送到主干，那么它是如何被推送到发布分支的呢

为什么错误修复会被挑选并合并到发布分支中？这意味着错误修复是在一个发布分支中完成的，而发布分支合并到master中

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

如果代码应该被直接推送到主干，那么它是如何被推送到发布分支的呢

发布分支的目标是让您集中精力准备发布软件，而不必担心主干中发生的事情。当团队的其他成员通过直接提交到

trunk

，继续为下一个版本而努力时，您可以通过修复

release

分支中剩余的bug来稳定选择发布的快照

在此稳定过程中，您可能会发现

中继中也存在bug。当这种情况发生时，您需要将版本
分支合并回主干
，以集成这些错误修复
为什么错误修复会被挑选并合并到发布分支中？这意味着错误修复是在一个发布分支中完成的，而发布分支合并到master中
当您在release
分支中稳定软件时，团队的其他成员可能会在trunk
中发现同样存在于release
中的bug。如果出现这种情况，您将希望在发行版中集成bug修复，但是，您不能将主干
合并到发行版
，因为这将带来团队在您准备发行版时一直在处理的所有新内容。因此，取而代之的是，您只选择修复bug的提交，而不选择其他内容
假设代码没有直接推送到发布分支，那么如果发布分支是从master分支出来的，为什么要将其合并回master/trunk呢
见答案1。请注意，如果trunk中的代码与最初为发布选择的代码相差太远，则将发布分支合并回trunk可能会导致大量合并冲突。例如，您可能已修复了发行版
中的一个bug，但由于重构，修改后的文件不再位于主干
中
还值得一提的是，发布分支并不总是值得额外的开销。您链接到的文档：
在一天多次发布的情况下，根本不需要发布分支，因为可以将更改直接推送到master中并从那里部署
其目标是通过将您必须维护的分支数量减少到一个分支来简化软件开发过程。
对于问题1，他们说发布分支的代码可以合并到主干中，而不是相反