代码流转模型流转链路开发 → 集成 → 测试 → 验收 → 发布 → 回滚质量维度速查表维度核心问题关键实践 可追踪代码→需求的映射是否清晰Commit 绑定需求ID制品版本号与源码强关联流水线日志永久留存⏪ 可回滚出故障能否快速恢复Git 历史可切镜像版本化管理发布系统支持一键回滚目标 1分钟 可审计操作记录能否作为证据链全流程记录“谁、何时、做了什么、结果”审批单永久留存且不可篡改 可协作多人并行是否有序无冲突分支策略清晰环境占用有锁机制发布前后自动通知相关方逐环节落地检查清单环节可追踪可回滚可审计可协作开发提交绑定需求单可切任意历史版本提交人有实名记录合并冲突有协商机制集成流水线日志完整失败构建不影响线上触发人和构建参数可查构建资源排队共享测试测试报告归档测坏可重置环境测试准入有签字记录环境占用状态可见验收验收版本与代码分支对应验收环境可快速重建验收人有电子签名产品经理可实时查看进度发布生产版本号可查必须有回滚按钮发布操作人有审批记录发布前发送变更公告回滚回滚操作有日志回滚失败可再回滚回滚事故需复盘归档回滚决策同步业务方一句话总结追踪找问题 ·回滚保命 ·审计免责 ·协作提效分支结构master -生产代码绝对稳定打tag prod -预发布/待上线test-测试环境公共分支 dev -开发主干所有开发最终汇总 feature/* -新功能开发分支 feature/order-pay feature/user-center feature/report-export bugfix/* -普通bug修复分支 bugfix/pay-error bugfix/login-error hotfix/* -线上紧急修复分支 hotfix/prod-20260101 核心思想分支按“功能”划分分支职责分支按照【代码生命周期】划分不是按照人员划分。代码的一生最核心流程:代码的一生 开发功能 ↓ feature/order-export ↓ dev ↓ test ↓ prod ↓ master ↓ tag v1.3.0 ↓ 生产部署master生产分支只能 prod -master 禁止 开发人员直接提交 特点1、永远可发布2、对应线上代码3、必须打 tag v1.0.0 v1.0.1 v1.1.0 上线gitcheckout mastergitmerge prodgittag v1.2.0prod预发布分支作用待上线代码。 流程 test验证通过 ↓ merge 到 prod ↓ UAT/验收 ↓ 上线 master 特点1、接近生产2、不允许乱提交3、只接受test合并test测试分支作用测试环境统一集成。测试人员永远测 test不要分test1、test2后期容器乱。 流程 feature/* ↓ merge 到 dev ↓ dev 稳定后 ↓ merge 到testdev开发主干所有开发汇总。 流程 feature/* ↓ merge 到 dev 特点1、允许不稳定2、每天持续集成3、自动构建开发功能工作流程Step1从dev拉功能分支# 切换 devgitcheckout dev# 查看当前分支gitbranch# 拉取dev最新代码gitpull origin devStep2创建feature分支# 创建 feature 分支 dev代码复制到feature分支gitcheckout-bfeature/order-export# 查看当前分支gitbranchStep3开发提交# 查看修改gitstatus# 查看差异gitdiff# 添加gitadd.# 提交gitcommit-mfeat: 订单导出支持Excel# 推送远程仓库# 第一次推gitpush-uorigin feature/order-export# 以后gitpushFeature→ Dev流程Step1同步最新dev# 切换devgitcheckout dev# 查看当前分支gitbranch# 拉代码gitpull origin dev# 切回功能分支gitcheckout feature/order-export# 查看当前分支gitbranch# 合并最新devgitmerge dev# 如果冲突解决冲突然后提交gitadd.gitcommit-mmerge: 合并dev最新代码Step2发起MRGit平台创建MRMerge Request方向feature/order-export-dev审核Code Review通过merge。Dev→ Test流程负责人操作# 切换testgitcheckouttest# 更新gitpull origintest# 合并devgitmerge dev# 提交gitpush origintest# 结果dev - testTest → Prod流程场景:测试环境验证通过功能正常无阻塞bug可以发布。# 1、切换 prod 分支gitcheckout prod# 2、拉取最新 prodgitpull origin prod# 3、合并 testgitmergetest# 3.1、如果没有冲突# 推送gitpush origin prod# 3.2、如果存在冲突# 查看gitstatus# 解决冲突。# 然后gitadd.# 提交gitcommit-mmerge: 合并test测试版本#推送gitpush origin prodProd环境部署预发布服务器UAT测试产品验收业务确认。Prod → Master流程上线前检查1、prod测试通过2、UAT通过3、数据库脚本准备完成4、配置文件检查完成5、回滚方案准备完成# 1、切换 mastergitcheckout master# 2、更新 mastergitpull origin master# 3、合并 prodgitmerge prod# 解决冲突# 查看状态gitstatusgitadd.gitcommit-mrelease: 发布v1.3.0版本# 4、推送 mastergitpush origin masterMaster打Tag版本管理为什么需要Tagmaster代表线上代码但是线上有很多版本例如 2026-01版本 2026-02版本 2026-03版本 需要记录哪个代码对应哪个发布版本怎么记录 Tag就是代码版本标记Tag 命名规范推荐语义化版本v主版本.次版本.修订版本例如 v1.0.0 v1.0.1 v1.1.0 v2.0.0 说明v1.0.11 1:重大版本 0:功能版本 11:bug修复版本创建Tag# 当前master# 创建gittag v1.3.0# 查看gittag# 推送 Taggitpush origin v1.3.0# 推送所有 Taggitpush origin--tags查看Tag对应代码gitshow v1.3.0删除Tag本地删除gittag-dv1.3.0远程删除gitpush origin--deletev1.3.0HotFix线上紧急修复流程紧急场景线上出现库存扣减错误,支付异常,严重接口bug 特点不能等待正常发布流程,需要立即修复。为什么不能从dev修因为dev可能有 - 未完成功能 - 半成品代码 - 测试代码 线上 必须基于master修复Hotfix流程master ↓ hotfix/* ↓ master ↓ prod ↓ test ↓ devStep1从master创建hotfix切换mastergitcheckout master拉最新gitpull origin master创建gitcheckout-bhotfix/stock-error# 结果master复制到hotfix/stock-errorStep2修复代码修改库存扣减逻辑查看gitstatus提交gitadd.commitgitcommit-mfix: 修复库存扣减错误推送gitpush-uorigin hotfix/stock-errorStep3Hotfix合并master创建MR方向hotfix/stock-error -- master审核通过merge或者切换gitcheckout master合并gitmerge hotfix/stock-error推送gitpush origin master此时线上代码修复完成。Step4Master打补丁Tag例如当前版本v1.3.0修复v1.3.1创建gittag v1.3.1推送gitpush origin v1.3.1Step5回灌Prod为什么要回灌保证后续发布包含修复切换gitcheckout prod更新gitpull origin prod合并mastergitmerge master推送gitpush origin prod# 结果master -- prodStep6回灌Test切换gitcheckouttest更新gitpull origintest合并gitmerge master推送gitpush origintest# 结果master -- testStep7回灌Dev切换gitcheckout dev更新gitpull origin dev合并gitmerge master推送gitpush origin dev最终hotfix/stock-error ↓ master ↓ prod ↓ test ↓ devMR/PR流程一、什么是MR/PRMRMerge Request(合并请求)PR:Pull Request拉取请求简单来说它们是同一个东西只是名字不同。PR 是 GitHub 的叫法MR是 GitLab 的叫法。 如果非要说区别PR偏向“请来拉”MR偏向“请去合”。作用开发人员请求把自己的代码合并到目标分支例如你的功能 feature/order-export开发完成。不能直接feature/order-export ↓ dev而是提交MRfeature/order-export ↓ dev然后由其他人审核。二、为什么需要MR如果没有MR流程张三写代码 ↓ 直接 merge dev ↓ 测试 ↓ 上线问题没人知道改了什么为什么改有没有风险有没有隐藏bug有 MR流程开发人员 ↓ 提交 MR ↓ Code Review ↓ 审核通过 ↓ merge代码进入主分支前必须经过检查。三、MR完整流程场景开发订单导出功能分支feature/order-export目标devStep1确认代码已经提交查看状态gitstatus应该nothing to commit查看提交记录gitlog--oneline例如a8f321 feat: 新增订单导出功能Step2推送远程分支第一次gitpush-uorigin feature/order-export以后gitpush推送完成远程仓库出现feature/order-exportStep3进入Git平台例如GitLab进入项目点击Merge requests点击New merge requestStep4选择源分支和目标分支Source branch选择feature/order-export意思我要合并谁Target branch选择dev意思合并到哪里最终feature/order-export ↓ devStep5填写MR信息标题规范类型: 功能描述例如feat: 新增订单导出功能描述建议模板## 需求 订单列表增加Excel导出功能 ## 修改内容 1. 新增导出接口 2. 增加Excel生成工具 3. 增加权限校验 ## 测试情况 本地测试通过 ## 影响范围 订单模块 ## 注意事项 无Step6指定Reviewer选择Reviewer例如张三 李四规则普通代码至少1人Review核心模块例如支付库存权限数据库至少2人ReviewStep7提交MR点击Create merge request状态Open表示等待审核。Step8Code Review审核人员检查代码是否符合规范是否存在bug是否影响其他模块提出Comment例如这里可能存在空指针风险 建议增加非空判断开发人员修改gitadd.gitcommit-mfix: 优化订单导出空指针处理gitpushMR自动更新。不需要重新创建。Step9审核通过状态Approved点击Merge最终feature/order-export ↓ dev权限规范master权限保护Protected Branch规则禁止直接push 禁止删除 禁止强制push 必须MR合并权限Maintainer才可以合并master发布版本创建tagprod权限规则禁止开发直接提交 只能通过MR进入来源test ↓ prod权限Maintainer Release负责人 技术负责人test权限规则开发禁止直接提交 通过dev合并来源dev ↓ test权限Developer可以创建MR Maintainer负责合并dev权限开发主干允许feature ↓ dev权限普通开发Developer可以push feature创建MR不能合并master删除保护分支feature权限每个人自己的开发分支。例如feature/order-pay feature/user-center开发人员拥有权限创建 提交 推送 删除权限模型角色权限普通开发Developer高级开发Developer Review组长/TLMaintainer架构师Maintainer发布负责人Maintainer测试人员Reporter分支规范分支master prod test dev feature/* bugfix/* hotfix/*开发流程feature ↓ dev ↓ test ↓ prod ↓ master ↓ tag紧急流程hotfix ↓ master ↓ prod ↓ test ↓ dev核心原则1、禁止直接修改master 2、禁止多人共用feature 3、禁止长期feature分支 4、所有代码必须MR 5、核心代码必须Review 6、线上版本必须Tag 7、生产问题必须回灌所有分支提交规范feat: 新功能 fix: 修复 refactor: 重构 perf: 性能优化 docs: 文档 style: 格式 test: 测试 chore: 构建gitcommit-mfeat: 新增订单接口gitcommit-mfix: 修复库存计算错误gitcommit-mrefactor: 重构JWT认证逻辑MR规范1、一个MR只做一件事情错误MR: 新增订单功能 修改登录 重构权限 修改数据库问题无法Review。正确MR1: 订单导出 MR2: 登录优化 MR3: 权限重构2、MR不要太大推荐代码300行以内比较容易审核。不要一次提交5000行Review基本失效。3、提交信息规范推荐feat: fix: refactor: perf:例如feat: 新增库存冻结接口 fix: 修复订单状态更新异常 refactor: 重构库存服务4、Review普通功能 开发人员 ↓ MR ↓ 1人Review ↓ merge dev 核心模块 开发人员 ↓ MR ↓ 2人Review ↓ TL审核 ↓ merge为什么一定要Code Review这是重点很多开发认为代码能跑就行但是企业项目不是只要求能运行还要求稳定、可维护、可扩展、安全1、发现业务逻辑错误例如库存扣减stock stock - quantity但是没有判断库存是否足够。测试数据100个库存正常。生产库存10购买20。结果库存变负数。Review可以提前发现。2、发现SQL问题例如开发ListOrder list orderMapper.selectAll();测试数据1000条没问题。生产5000万订单。直接数据库压力爆炸Review会检查是否分页是否索引是否全表扫描3、发现事务问题例如订单支付updateOrder();savePayment();updateStock();没有事务结果订单成功库存失败。导致数据不一致。Review会要求Transactional4、发现安全问题例如接口GetMapping(/user/{id})直接查询select*from user where idid没有权限校验。如果修改id查看别人信息。/user/10086Review发现权限漏洞。5、保证代码统一当团队很多人时如果没有Review可能出现张三try{}catch(Exceptione){}李四throwsException王五Result.error()最后代码风格混乱。Review统一异常处理日志规范命名规范返回结构6、降低人员风险如果只有一个人知道代码风险离职 没人维护Review让至少两个人了解代码。Code Review检查清单Java代码是否存在空指针 是否合理使用事务 是否存在重复代码 是否存在异常吞掉 日志是否合理 是否有敏感信息打印数据库SQL是否走索引 是否存在全表查询 是否需要分页 字段类型是否合理 是否需要事务性能是否循环查询数据库 是否N1问题 是否大量内存加载 是否存在慢接口安全参数校验 权限校验 SQL注入 数据越权MR解决代码怎么进入主干Code Review解决进入主干之前有没有质量问题MR Code Review不是形式而是保证项目长期可维护的基础。