开源项目GitFlow分支策略最佳实践及相关问题咨询

1. 旧版本Bug修复是否需要cherry-pick到所有新版本？ #

不是必须要cherry-pick到所有新版本，核心判断标准是这个bug是否存在于目标分支中：

• 如果该bug是旧版本（比如v1.2.x）特有的，后续新版本（如v1.3+）的代码逻辑已经重构或修复了这个问题，那么无需cherry-pick；
• 如果该bug是跨版本存在的（比如v1.2、v1.3、main分支都有这个问题），则需要将修复提交cherry-pick到所有受影响的发布分支以及main分支。

实践中更高效的方式是：如果这个bug是通用问题，优先在main分支修复，再将修复提交cherry-pick到各个需要的旧发布分支；如果是旧版本专属bug，就在对应发布分支修复后，评估是否需要同步到其他分支。另外，GitLab自带的cherry-pick功能（在合并请求或提交详情页）可以简化这个操作，减少手动命令的出错概率。

2. 发布候选版本（RC）的最优处理方式 #

不需要单独创建v1.2rc_1这类分支，更简洁的实践是基于发布分支用tag来管理RC版本：

• 当准备发布v1.2系列时，先创建release/v1.2分支；
• 在release/v1.2分支上直接打v1.2-rc1的tag，基于这个tag构建测试版本；
• 如果测试中发现bug，直接在release/v1.2分支上修复，修复完成后打v1.2-rc2的tag，重复测试流程；
• 当RC版本通过所有测试后，在release/v1.2分支上打正式的v1.2.0 tag，完成发布。

这种方式避免了分支泛滥，同时通过tag清晰区分不同阶段的候选版本。如果确实需要针对RC版本做临时的测试专属修改（比如添加测试埋点），可以临时创建release/v1.2-rc1分支，测试完成后将必要的修复合并回release/v1.2分支，再删除临时RC分支。

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