基于GitFlow的热修复、Bug修复与版本管控方案问询

背景：我采用GitFlow管理一款应用，Release 1.0.0已上线App Store，Release 2.0.0正处于release/2.0.0分支的测试阶段。针对以下三个场景，对应的GitFlow操作方案如下：

场景1：用户反馈1.0.0版本存在严重Bug，需立即发布新版本 #

• 从main分支（对应已发布的v1.0.0标签）创建热修复分支，命名示例：hotfix/1.0.1
• 在热修复分支上完成Bug修复，本地验证修复效果
• 给该分支打发布标签：git tag -a v1.0.1 -m "Fix critical bug in 1.0.0"
• 发布版本1.0.1到App Store
• 将热修复分支合并至main分支和develop分支，确保线上版本和后续开发分支都包含该修复
• 删除热修复分支

场景2：用户反馈Bug，需修复后纳入下一个版本2.0.0 #

• 从develop分支创建Bug修复分支，命名示例：bugfix/login-crash（用关键词命名便于识别）
• 在修复分支上完成Bug修复并通过测试
• 将修复分支合并回develop分支
• 后续release/2.0.0分支最终合并到main时，develop分支的修复会自动同步；若需提前让release分支包含该修复，也可将bugfix分支合并到release/2.0.0分支，同时记得同步回develop分支避免代码不一致

场景3：QA在release/2.0.0分支上发现Bug时如何操作？ #

• 直接在release/2.0.0分支上进行Bug修复（release分支的核心作用就是处理发布前的最后调整）
• 修复完成后在该分支上完成测试验证
• 待release分支测试通过后，合并至main和develop分支时，该修复会同步到两个分支
• 若修复逻辑复杂，可临时从release/2.0.0创建修复分支，完成后合并回release分支，再执行后续合并流程

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