Git-flow工作流中如何规范处理发布候选版本(RC)

现有方案：单大版本release分支承载RC迭代，终版合入main #

也就是你们当前在用的模式：为单个正式大版本（比如v1.0.0）建唯一的release/1.0.0分支，所有RC版本都以该分支上的标签形式存在，等正式版验证通过再把分支合入main。

• 这是原生Git-Flow模型定义的标准操作，也是行业内最通用的处理方式
• 实际使用的优势非常明显：
  • 分支拓扑干净，整个v1.0.0版本从RC到正式版的所有bugfix、调整都收敛在同一条release分支上，不会产生大量零散的冗余分支
  • 完全符合main分支的定位：只存放经过完整验证、可随时部署到生产的稳定代码。RC本质是带已知问题、仅供测试/小范围验证的预览版，本来就不应该进入稳定基线
  • 操作成本极低：发RC只需要在release分支的对应提交上打v1.0.0-rc.x格式的标签即可，不需要反复做跨分支合并、冲突处理，很少会出现人为操作失误
  • 版本回溯方便，找某个大版本的所有发布前变更，直接查对应release分支的提交记录就行
• 适用场景覆盖绝大多数团队：只要你们的RC版本是用于内部测试、小范围灰度，不对用户承诺RC版本的稳定性，用这个方案就不会出问题。唯一要注意的是RC阶段在release分支上提交的bugfix，要定期同步回develop分支，不要等正式发布才一次性合并，避免攒出大的代码冲突。

研讨提出的新方案：每个RC单独建release分支，发RC即合入main #

也就是每个RC版本（比如v1.0.0-rc.0）单独建release/1.0.0-rc.0分支，发布时就把分支合入main。

• 这个方案完全偏离了Git-Flow的核心分支设计逻辑，我接触过的落地Git-Flow的团队里几乎没有这么做的，踩坑概率极高
• 核心问题有三个：
  • 直接污染main分支的稳定基线：RC版本本身就是未经过全量验证的版本，大概率带待修复的问题，把这些代码合入main之后，万一线上出紧急故障需要从main切hotfix分支，很容易把没测完的RC代码带到生产，平白拉长故障处理时间
  • 维护成本陡增：每发一个RC就要走一遍建分支、合main、处理冲突的流程，后续RC的bugfix还要在多个分支间反复同步，非常容易出现代码漏合、版本号错配的问题
  • 版本追溯困难：同一个大版本的变更散落在多个独立的release分支上，后续排查线上问题、回溯版本迭代路径的时候，要跨好几个分支找提交记录，排查成本很高
• 只有一种极特殊场景可以考虑这种模式：你们的RC版本是合同约定的、需要正式交付给客户的里程碑节点，每个RC交付后就会作为独立版本长期维护、不会再基于它迭代后续同大版本的RC——但这种场景本质是把每个RC当成独立正式版发布，更适合用GitHub Flow这类主干开发模型，硬套Git-Flow反而别扭。

行业落地的最佳实践参考 #

• 没有特殊需求的话，直接沿用你们现在的单release分支+RC标签的方案就行，这是经过十几年行业验证的成熟模式，没必要为了“分支隔离”搞多余的设计
• 不用单独给RC建分支也能满足RC版本的可追溯需求：Git标签本身就是不可变的版本快照，打RC标签之后把标签推到远端，任何时候需要拉某个RC版本的代码，直接基于对应标签拉取即可，完全能满足交付、回溯的要求
• 实操层面几个可以优化的细节：
  • 所有RC标签严格遵循语义化版本格式，统一用v<主版本>.<次版本>.<修订版本>-rc.<序号>的规则命名，避免标签混乱
  • release分支上的bugfix不要攒到正式发布才同步，每发一个RC就把对应提交合回develop一次，减少后续合并的冲突概率
  • 正式版本发布完成后，及时把release分支合入main并打正式版本标签，再把release分支合回develop后删除远端的对应release分支，保持分支列表整洁
  • 永远不要把未达到生产稳定标准的代码合入main，main上的所有标签都应该对应正式发布的稳定版本，hotfix分支永远从main的最新正式标签切出

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