基于主干的开发中，多Release分支的Bug修复合并方案疑问

背景 #

我们正在适配带Release候选分支的主干开发模式，当前遇到核心问题：当修复了已发布的Release 1的严重Bug后，如何安全地将该修复同步到Release 2（无论Release 2是否发布）。现有两种思路：直接合并基于Release 1的热修复分支到Release 2，或是从主干cherry-pick对应的修复提交到Release 2。后者是行业通用方案，但前者看起来更直接，因此需要明确两种方案的差异。

直接合并热修复分支的隐藏风险 #

你忽略了Release分支间的代码基线差异带来的核心问题：

• 合并冲突与兼容性问题：Release 2是在主干经过多次修改后创建的，其代码基线和Release 1已经存在差异。热修复分支基于Release 1的旧基线开发，直接合并到Release 2时，很可能出现大量合并冲突；即使冲突解决，修复逻辑也可能因为Release 2的代码上下文变化而失效，甚至引入新Bug。
• 版本历史混乱：合并热修复分支会将该分支的所有提交（包括与Release 2无关的基线依赖提交）带入Release 2的历史，导致后续版本溯源、Bug排查时难以区分本版本功能与跨版本热修复的边界。
• 测试覆盖缺失：热修复仅在Release 1的环境下验证过，直接合并到Release 2后，没有针对Release 2的代码环境做针对性测试，存在未验证的风险。

为什么Cherry-Pick是更优的通用方案 #

1. 精准可控：cherry-pick只会将修复Bug的单个/相关提交同步到Release 2，不会引入任何无关代码，完全避免了合并主干或热修复分支带来的冗余变更。
2. 历史清晰可溯源：使用git cherry-pick -x可以自动在新提交中添加原提交的哈希值，明确标注该修复来自哪个热修复，后续审计、排查问题时一目了然。
3. 冲突范围更小：即使遇到冲突，也只需要针对Bug修复的代码块进行解决，范围远小于合并整个热修复分支，降低了出错概率。
4. 符合主干开发的核心原则：主干是所有稳定变更的唯一权威来源，热修复先合并到主干，再从主干同步到其他Release分支，保证了所有分支的变更都能追溯到主干，避免了多分支交叉合并导致的版本混乱。

优化cherry-pick流程的建议 #

如果担心人为操作出错，可以通过以下方式优化：

• 强制使用git cherry-pick -x参数，保留原提交溯源信息
• 借助CI/CD工具，自动化检测主干中的热修复提交是否已同步到所有需要的Release分支
• 制定明确的流程规范：所有热修复必须先合并到主干，再由专人负责同步到其他Release分支，避免遗漏或错误

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