双发布分支热修复最优策略咨询：规避版本历史混乱与冲突

背景 #

当前存在两个并行发布分支，分别对应prod和alpha环境：

• release/1.1.0（prod环境）：最新提交为123abc，已打标签v1.1.0
• release/1.2.0（alpha环境）：最新提交为456def，已打标签v1.2.0
• release/1.1.0的提交历史完全包含在release/1.2.0中，后者仅多1个功能提交
• 使用语义化版本工具，基于约定式提交自动升级版本、更新changelog并打标签

问题 #

prod环境的v1.1.0出现错误后，基于其创建热修复分支，修复后合并至release/1.1.0、release/1.2.0及dev分支。版本工具将release/1.1.0更新为v1.1.1，但release/1.2.0仍显示v1.2.0，导致：

• 分支历史分歧：release/1.2.0缺失v1.1.1的修复历史
• 分支名称与实际版本不符
• 后续热修复会引发changelog合并冲突，导致release/1.2.0版本历史混乱

现有思路评估 #

思路1：将release/1.2.0变基到热修复分支 #

• 优点：能让release/1.2.0继承完整的v1.1.1修复历史
• 缺点：操作繁琐，需先删除v1.2.0标签、撤销changelog提交，重新运行版本工具；变基会改写公共分支历史，可能影响其他协作开发者

思路2：在dev分支的release/1.1.0分支点重建分支 #

• 优点：能梳理清晰的版本历史
• 缺点：操作成本极高，需要迁移dev分支的所有后续提交，容易引入新的冲突和错误，且对现有分支结构改动过大

思路3：独立修复+Cherry Pick #

• 优点：操作简单直接，不破坏原有分支历史
• 缺点：若多次热修复，会产生大量重复的cherry pick提交，长期来看可能导致分支历史冗余

最优解决方案 #

推荐基于思路3优化的方案，核心是保持分支独立性，同时规范版本和changelog的管理：

1. 处理prod热修复

   • 基于release/1.1.0（或v1.1.0标签）创建热修复分支hotfix/1.1.1
   • 在该分支上完成修复，提交时使用约定式提交格式（如fix: 修复prod环境XX问题）
   • 运行版本工具，自动升级版本到v1.1.1，更新changelog，打标签v1.1.1
   • 将hotfix/1.1.1合并到release/1.1.0（或直接将release/1.1.0指向v1.1.1并删除旧分支），同时合并到dev分支

2. 同步修复到alpha分支

   • 从hotfix/1.1.1中提取修复提交（仅提取代码修复部分，排除版本工具自动生成的changelog和版本号提交）
   • 将该修复提交cherry pick到release/1.2.0分支
   • 在release/1.2.0上运行版本工具，自动升级版本到v1.2.1，更新changelog，打标签v1.2.1
   • 将release/1.2.0的更新合并到dev分支

3. 避免changelog冲突的关键

   • 确保版本工具生成的changelog是基于分支提交历史自动生成的，不要手动修改changelog内容
   • cherry pick时仅选择代码修复的提交，跳过版本工具自动生成的版本升级和changelog提交，避免重复写入changelog条目

主干开发模式过渡建议 #

针对当前转向主干开发但需维持双环境的情况，可采用以下过渡方案：

• 逐步引入特性开关（Feature Flags）：将release/1.2.0中的新增功能用开关包裹，合并到主干分支，通过开关控制prod和alpha环境的功能展示
• 取消长期并行的release分支，改为基于主干分支创建临时的发布分支：prod环境使用主干的稳定标签发布，alpha环境使用主干的最新提交（带特性开关）发布
• 热修复直接在主干分支进行，然后基于主干创建对应的补丁版本分支，分别部署到prod和alpha环境

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