不将release分支合并回develop的影响及Git分支策略咨询

分支职责对齐建议 #

你可以先明确分支用途避免后续混乱：

• 保留master作为开发基准分支，所有feature分支的合入目标都是master
• 把目前未明确用途的main分支专门对应生产环境的稳定版本，所有正式上线的代码最终都要更新到main

临时hotfix不合入开发分支的实现方案 #

你遇到的属于特定旧版本临时兼容的例外场景，不需要完全遵守GitFlow/OneFlow的标准合并规则，操作步骤如下：

• 从本次出问题的生产对应release版本的提交/标签上，拉取专属hotfix分支，命名可参考hotfix/vx.y.x-legacy-worker-compat
• 在该分支上完成作业模板的兼容性修改，自测验证通过后直接部署到生产环境
• 跳过往master开发分支合并的步骤，仅在团队内部文档备注该hotfix的适用范围、不合入开发分支的原因即可（标准流程是通用规范，针对后续版本会废弃的临时兼容补丁，完全可以灵活调整规则）

不删除release/hotfix分支的可行策略 #

完全存在不需要删除这两类分支的管理方案，你可以调整分支生命周期规则如下：

• feature分支：合并到master后即可删除，这类分支迭代快数量多，长期保留意义不大
• release分支：每个正式发版的release分支永久保留，命名带明确版本号，比如release/v1.2.0，对应每次发生产的版本候选
• hotfix分支：通用问题修复类的hotfix合并到主干后可删除，针对单版本的临时兼容类hotfix，和对应release分支绑定永久保留即可

保留release和hotfix分支的影响 #

• 有利影响：
  • 随时可以回溯任意历史版本的发布状态、修改记录，不需要依赖标签翻找历史提交
  • 后续需要针对某个旧版本做修改时，直接从对应release分支拉取代码即可，效率更高
  • 排查线上问题时可以直接切换到对应release分支复现，和生产运行的代码完全一致
• 不利影响：
  • 仓库分支列表会随着版本迭代越来越长，需要严格遵守命名规范避免使用混乱
  • 长期不活跃的分支会占用极少量的仓库存储，对Git仓库的运行基本无影响

标签机制运作规则 #

建议使用语义化版本的附注标签，规则参考如下：

• 每次release版本正式上线生产后，给对应release分支的最新提交打正式标签，格式为v<主版本号>.<次版本号>.<修订号>，比如v1.2.0
• 通用修复类hotfix上线后，直接升级修订号打标签，比如v1.2.1
• 临时兼容类hotfix上线后，给对应hotfix分支的最新提交打带后缀的标签，比如v1.2.0-hotfix-legacy-worker，明确标识是特定版本的临时补丁
• 所有正式标签仅打对应生产环境运行的提交，不要给开发中的提交打正式标签，避免版本混淆

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