Git Flow中release分支修复bug后合并回master的最佳策略咨询

核心结论 #

正确操作是选项2：当release分支完成所有必要bug修复、达到可上线标准后，同时将该分支分别合并回develop分支与master分支。

具体原因说明 #

结合Git Flow的分支定位设计，我们可以很清晰地判断两个操作路径的合理性：

• 选项1的操作路径（release先合回develop，再从develop合回master）不符合Git Flow的核心设计原则
  • 极易引入未验证的风险代码：master分支的核心职责是永久保存可直接部署的生产稳定版本代码，每一次正式上线，都对应master上一个打了明确版本号标签的提交。而release分支的本质，就是从develop切出来的“发版隔离缓冲区”——团队在这个分支上集中做发版前的bug修复、版本号调整、回归测试，核心目的就是确保从这里出去的代码是可以直接上生产的。如果按照选项1的流程操作，等你把release上的修复合回develop之后，develop分支很可能已经叠加了多轮新的、还没经过发版验证的功能代码，这时候再把develop合到master，相当于把这些未经过上线校验的新代码也带进了本次的生产发布版本里，直接破坏了master分支只存生产稳定代码的定位。
  • 额外增加合并成本：拉长的合并链路会放大release分支与生产分支的代码差异，导致后续合并时出现大量无意义的冲突，拖慢发版节奏。
• 必须同时将release分支的改动分别合入两个分支的核心原因
  • 合入master：因为release分支上的代码已经通过全部上线前的回归验证，直接作为生产版本同步到master，不需要经过develop中转，能最大程度保障生产代码的纯净度，避免混入未完成验证的迭代内容。
  • 合入develop：在release分支上修的所有bug，根源都是之前从develop流出去的旧代码遗留问题。如果只把这些bug修复合到master、却不把补丁同步回develop，等下一轮迭代切新的release分支准备发版时，这些已经修过的bug会因为develop上的代码没有对应修复，再次出现在新的待发版分支里，导致团队重复踩同一个坑、重复修同一个问题。

配套收尾操作 #

完成两个分支的合并后，只需要在master分支的对应提交上打上正式的版本号标签，等确认线上发布稳定后，就可以删除已经完成使命的release分支了。

内容的提问来源于stack exchange，提问作者David Kohelet