master非生产基准场景下如何优化多版本与热补丁管理Git工作流

核心调整：新增独立的生产基准分支 #

• 新增prod分支，作为生产运行代码的唯一可信源，所有生产发布的代码最终必须合并到该分支，权限设置为只有发布管理员可以合并，开发人员无直接推送/合并权限
• 原有master分支保留作为开发集成分支，所有feature分支仍然从master拉取，开发完成合并回master，和现有开发习惯完全兼容，无需调整现有开发流程

大版本发布流程（与原有流程差异极小） #

1. 待master上的功能满足发布条件时，从master拉取对应版本的release/X.Y.Z分支，修改pom版本号为X.Y.Z.0，构建ear包部署到acceptance环境验证
2. 验证过程中发现的问题直接在release/X.Y.Z分支修复，修复完重新构建验证
3. 验收通过正式上线到生产后，同步执行三个操作：
   • 把release/X.Y.Z分支合并到prod分支
   • 在prod分支打vX.Y.Z.0的tag
   • 把release/X.Y.Z分支合并回master，pom版本冲突仅需处理一次，后续该版本的热补丁合回master时无需反复处理版本问题
4. 归档release/X.Y.Z分支，后续该版本的所有热补丁都从对应tag拉取

热补丁发布流程（解决现有痛点） #

1. 生产需要打热补丁时，直接从prod分支上对应当前生产版本的tag（比如vX.Y.Z.0）拉取hotfix/X.Y.Z.1分支，修改pom版本号为X.Y.Z.1，在该分支完成修复
2. 构建ear包部署到acceptance环境验证，验证通过后上线生产
3. 上线完成后同步执行三个操作：
   • 把hotfix/X.Y.Z.1合并到prod分支
   • 在prod分支打vX.Y.Z.1的tag
   • 把hotfix/X.Y.Z.1合并回master，如果有pom版本冲突仅需处理当前修复的代码部分，不会影响其他开发中的功能
4. 无需保留的热补丁分支可直接归档处理

Gitlab侧配套规则配置（利用平台能力降低人工成本） #

• 给prod、master分支设置保护规则，禁止直接推送，所有合并必须走合并请求（MR）
• 针对hotfix和release类型的MR，可配置CI自动校验版本号格式是否符合规则，不符合直接拦截
• 可配置合并时自动删除源分支，减少冗余分支堆积
• pom版本冲突的问题，可在.gitattributes里配置pom.xml的合并策略，或设置规则要求master分支的版本号永远高于所有已发布的版本，合并热补丁的时候直接保留master的版本号即可，无需人工判断

方案优势 #

• 完全兼容现有开发习惯，无需调整feature分支的开发合并流程，开发人员学习成本极低
• 彻底解决生产代码可信源的问题，prod分支永远和线上一致，拉取热补丁分支无需再专门查找历史tag
• 减少合并冲突的处理频率，大版本发布时仅需处理一次release分支合回master的版本冲突，后续热补丁合入的冲突量会大幅降低
• 不需要完全切换到复杂的Git-flow，仅新增两类分支，维护成本很低

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