GitFlow工作流热修复整合与版本发布管理问题咨询

问题根因说明 #

你当前遇到的问题核心来自流程偏差：标准GitFlow规则中，正式版本号的标签仅允许打在main分支的生产发布节点上，你方将版本标签打在develop分支的操作，会导致标签对应的代码节点无法自动同步后续生产环境的热修复内容，自然会出现旧版本标签节点不带热修的问题。你方功能集与版本号绑定的规则本身没有问题，仅需要调整标签落点、分支切取和热修复同步逻辑即可解决。

目标场景（发布带历史热修复的v1.0.6版本）操作步骤 #

• 1. 定位提交节点：找到两个关键提交，一是main分支上之前v1.0.5版本对应的热修复合入提交（记为hotfix_fix_xxx_commitid，这个提交是已经在生产验证过的有效修复代码），二是develop分支上功能集{D,E,F}开发完成的对应提交节点（也就是你之前标记v1.0.6功能完成的节点）
• 2. 切出待发布分支：从develop分支的v1.0.6功能完成节点，切出release/v1.0.6分支，不要直接用之前打在develop上的v1.0.6标签切分支
• 3. 同步热修复代码：在release/v1.0.6分支上执行cherry-pick hotfix_fix_xxx_commitid，将热修复代码拣选到当前待发布分支，如果出现代码冲突，直接在release分支解决后提交即可。不要直接将main分支合并到release分支，避免把main上更高版本（比如v1.0.7~v1.0.10）的无关代码带入待发布版本
• 4. 按流程验证发布：将带热修复的release/v1.0.6分支流转SIT、预发环境，重点回归热修复内容和v1.0.6新功能的兼容性，验证通过后将分支合入main分支，正式发布生产，同时在main分支的本次发布节点打正式的v1.0.6版本标签
• 5. 同步代码回开发分支：将发布完成的release/v1.0.6分支反向合并回develop分支，保证开发分支的代码基线包含所有已发布的热修复内容

业内通用版本&热修复管理规则（从根源避免同类问题） #

• 正式版本标签仅打在main分支的生产发布节点，develop分支上的功能完成节点不要打正式版本号标签，可以打dev-v1.0.6-func-complete这类临时标识标签，和正式发布标签做明确区分，避免分支切取时混淆
• 所有生产热修复合入main分支后，除了合并到当前最新的develop分支，必须第一时间排查所有处于待发布状态的release分支，将热修复提交通过cherry-pick同步到所有待上线的分支上，不要等到临发布才补代码
• 如果存在多版本并行维护的情况（比如同时维护v1.0.x、v1.1.x两条客户在用的版本线），每个维护版本拉取独立的长期release分支，热修复需要同步拣选到所有仍在维护周期内的版本分支
• 版本发布前增加强制校验步骤，检查当前待发布的release分支是否包含生产环境已上线的全部热修复提交，校验不通过不允许进入发布流程

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