如何使用GitHub Flow为多个已发布版本分支应用热修复

场景回顾 #

已发布并维护v0.0.1、v0.0.2版本，当前在master分支开发即将发布的v0.0.3版本（master分支稳定但未完成全部功能）；现发现v0.0.1存在一个严重BUG，且该BUG也存在于v0.0.2和未部署的v0.0.3中。

热修复具体步骤 #

• 从最早受影响的发布分支拉取修复分支
  直接基于v0.0.1分支创建热修复分支，比如命名为hotfix/critical-core-bug（根据BUG类型命名）。这么做是为了确保修复代码只针对BUG本身，不会带上v0.0.2或master里的新功能，避免给旧版本引入额外风险。
• 在修复分支上完成BUG修复与测试
  只专注修复这个严重BUG，别加其他功能改动。修复完后做全面测试，确保BUG彻底解决，同时不影响旧版本的原有功能。
• 依次合并修复分支到所有受影响分支
  1. 先合并到v0.0.1分支，合并后打新的版本标签v0.0.1b（或者用v0.0.1.1这种补丁版本号，看项目的版本规则），然后发布这个修复版给还在使用v0.0.1的用户。
  2. 接着把修复分支合并到v0.0.2分支，同样打新标签v0.0.2b，发布对应的修复版本。
  3. 最后合并到master分支，确保即将发布的v0.0.3也包含这个修复。如果合并时遇到冲突，直接解决就行，之后测试master分支的稳定性，继续v0.0.3的开发。
• 清理临时修复分支
  所有分支都合并完成后，删掉刚才创建的hotfix/xxx-severe-bug分支即可。

问题解答 #

是否需要从master分支拉取修复分支并合并到每个发布分支？ #

不需要，反而应该从最早的受影响发布分支（也就是v0.0.1）拉取修复分支。master分支有v0.0.3的未完成功能，从这里拉分支会把未经过充分测试的新代码带入旧版本修复，反而容易出问题。从旧版本分支拉修复，能保证代码最小化，兼容性更好。

是否需要为每个发布分支更新版本号？ #

必须更新。每个修复后的发布分支都要打新的版本标签，这样用户能清楚区分修复前后的版本，也方便后续的维护和问题追溯。版本号格式可以灵活选，比如补丁号递增（v0.0.1.1）或者加后缀（v0.0.1-hotfix1），只要团队能统一识别就行。

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