Git Flow中RC与Hotfix共存场景的处理方案问询

这个场景在Git Flow实践里确实是个棘手的冲突点，我来分享几个经过验证的可行方案，你可以根据团队的实际情况选择：

解决方案一：废弃现有RC，基于Hotfix后的Master重建新RC #

这是最贴合Git Flow原始规范的做法，适合当前RC测试进度还比较早期、改动内容不多的情况：

• 先走完标准Hotfix流程：完成Hotfix分支的修复，合并到master和dev分支，给Hotfix打上版本标签（比如v1.0.1-hotfix）。
• 给当前待测试的RC分支打一个废弃标记（比如git tag rc-v1.0.0-abandoned），然后删除或归档这个分支，方便后续回溯。
• 从更新后的master分支拉出全新的RC分支（git checkout -b rc-v1.0.1 master）。
• 将原RC分支上的所有改动迁移到新RC分支：如果是少量提交，可以用git cherry-pick <commit-hash>逐个迁移；如果改动较多，也可以直接合并原RC分支到新RC（git merge rc-v1.0.0），解决冲突后继续测试。
• 基于新RC分支重新开展完整的测试，确保Hotfix和原有RC功能的兼容性。

这种方案的核心是保证RC分支从最新的生产稳定版本（带Hotfix）出发，避免上线后出现RC与master版本不一致的问题，同时也符合Git Flow中RC作为“完整预发布包”的定义。

解决方案二：临时将Hotfix修复Cherry-Pick到RC分支（灵活变通） #

如果当前RC已经接近测试完成、改动内容较多，废弃重建成本太高，可以尝试这种不违反Git Flow核心原则的临时操作：

• 先完成标准Hotfix流程：合并到master和dev，打版本标签。
• 找到Hotfix分支上的核心修复提交哈希值（可以用git log hotfix-v1.0.1查看）。
• 切换到RC分支，执行git cherry-pick <hotfix-commit-hash>，手动解决可能出现的代码冲突。
• 重点测试Hotfix修复点与原有RC功能的交互场景，确保没有引入新的问题。
• 测试通过后，正常上线RC分支到生产环境：此时RC包含了Hotfix修复，与master的状态一致，后续将RC合并到master时，因为Hotfix已经存在，只会合并RC的其他功能改动，不会有冲突。
• 上线完成后，将RC分支合并到dev分支：此时dev已经包含Hotfix，合并时只会处理RC的新增功能，冲突风险极低。

注意：这种方案的关键是Hotfix必须是独立的、影响范围小的修复，不能是涉及核心架构或大量依赖改动的修复，否则cherry-pick可能带来不可控的冲突或隐藏问题。

通用注意事项 #

• 无论选择哪种方案，都要确保最终上线的RC版本与master分支的状态一致，绝对不能让不含Hotfix的RC上线到已经有Hotfix的生产环境，避免出现版本割裂的问题。
• 操作过程中要做好分支和提交的记录，比如给废弃的RC打标记、在cherry-pick的提交信息里标注来源，方便后续团队成员回溯。
• 事后要复盘这次冲突的原因，比如是否RC的测试周期太长、Hotfix的触发是否可以提前预判，优化团队的分支管理和发布流程，减少这类冲突的发生。

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