代码流转模型

流转链路

开发 → 集成 → 测试 → 验收 → 发布 → 回滚

质量维度速查表

逐环节落地检查清单

一句话总结

追踪找问题 ·回滚保命 ·审计免责 ·协作提效

分支结构

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.0

prod

预发布分支，作用待上线代码。 流程： test验证通过 ↓ merge 到 prod ↓ UAT/验收 ↓ 上线 master 特点：1、接近生产2、不允许乱提交3、只接受test合并

test

测试分支，作用测试环境统一集成。测试人员永远测 test，不要分test1、test2后期容器乱。 流程： feature/* ↓ merge 到 dev ↓ dev 稳定后 ↓ merge 到test

dev

开发主干，所有开发汇总。 流程： feature/* ↓ merge 到 dev 特点：1、允许不稳定2、每天持续集成3、自动构建

开发功能工作流程

Step1：从dev拉功能分支

# 切换 dev：gitcheckout dev# 查看当前分支：gitbranch# 拉取dev最新代码：gitpull origin dev

Step2：创建feature分支

# 创建 feature 分支 dev代码复制到feature分支gitcheckout-bfeature/order-export# 查看当前分支：gitbranch

Step3：开发提交

# 查看修改：gitstatus# 查看差异：gitdiff# 添加：gitadd.# 提交：gitcommit-m"feat: 订单导出支持Excel"# 推送远程仓库# 第一次推：gitpush-uorigin feature/order-export# 以后：gitpush

Feature→ Dev流程

Step1：同步最新dev

# 切换dev：gitcheckout dev# 查看当前分支：gitbranch# 拉代码：gitpull origin dev# 切回功能分支：gitcheckout feature/order-export# 查看当前分支：gitbranch# 合并最新dev：gitmerge dev# 如果冲突：解决冲突，然后提交：gitadd.gitcommit-m"merge: 合并dev最新代码"

Step2：发起MR

Git平台创建MRMerge Request，方向feature/order-export->dev，审核Code Review，通过merge。

Dev→ Test流程

负责人操作

# 切换testgitcheckouttest# 更新：gitpull origintest# 合并dev：gitmerge dev# 提交：gitpush origintest# 结果：dev -> test

Test → Prod流程

场景:测试环境验证通过，功能正常，无阻塞bug，可以发布。

# 1、切换 prod 分支gitcheckout prod# 2、拉取最新 prodgitpull origin prod# 3、合并 testgitmergetest# 3.1、如果没有冲突：# 推送：gitpush origin prod# 3.2、如果存在冲突：# 查看：gitstatus# 解决冲突。# 然后：gitadd.# 提交：gitcommit-m"merge: 合并test测试版本"#推送：gitpush origin prod

Prod环境部署

预发布服务器，UAT测试，产品验收，业务确认。

Prod → Master流程

上线前检查

• 1、prod测试通过
• 2、UAT通过
• 3、数据库脚本准备完成
• 4、配置文件检查完成
• 5、回滚方案准备完成

# 1、切换 mastergitcheckout master# 2、更新 mastergitpull origin master# 3、合并 prodgitmerge prod# 解决冲突# 查看状态gitstatusgitadd.gitcommit-m"release: 发布v1.3.0版本"# 4、推送 mastergitpush origin master

Master打Tag（版本管理）

为什么需要Tag？

master代表线上代码，但是线上有很多版本例如： 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# 推送 Tag：gitpush origin v1.3.0# 推送所有 Tag：gitpush origin--tags

查看Tag对应代码

gitshow v1.3.0

删除Tag

本地删除：

gittag-dv1.3.0

远程删除：

gitpush origin--deletev1.3.0

HotFix线上紧急修复流程

紧急场景

线上出现：库存扣减错误,支付异常,严重接口bug 特点：不能等待正常发布流程,需要立即修复。

为什么不能从dev修？

因为dev可能有： - 未完成功能 - 半成品代码 - 测试代码 线上： 必须基于：master修复

Hotfix流程

master ↓ hotfix/* ↓ master ↓ prod ↓ test ↓ dev

Step1：从master创建hotfix

切换master：

gitcheckout master

拉最新：

gitpull origin master

创建：

gitcheckout-bhotfix/stock-error# 结果：master复制到hotfix/stock-error

Step2：修复代码

修改：

库存扣减逻辑

查看：

gitstatus

提交：

gitadd.

commit：

gitcommit-m"fix: 修复库存扣减错误"

推送：

gitpush-uorigin hotfix/stock-error

Step3：Hotfix合并master

创建MR，方向：hotfix/stock-error --> master

审核通过：merge

或者

切换：

gitcheckout master

合并：

gitmerge hotfix/stock-error

推送：

gitpush origin master

此时：线上代码修复完成。

Step4：Master打补丁Tag

例如当前版本：

v1.3.0

修复：

v1.3.1

创建：

gittag v1.3.1

推送：

gitpush origin v1.3.1

Step5：回灌Prod

为什么要回灌？保证后续发布包含修复

切换：

gitcheckout prod

更新：

gitpull origin prod

合并master：

gitmerge master

推送：

gitpush origin prod# 结果：master --> prod

Step6：回灌Test

切换：

gitcheckouttest

更新：

gitpull origintest

合并：

gitmerge master

推送：

gitpush origintest# 结果：master --> test

Step7：回灌Dev

切换：

gitcheckout dev

更新：

gitpull origin dev

合并：

gitmerge master

推送：

gitpush origin dev

最终：

hotfix/stock-error ↓ master ↓ prod ↓ test ↓ dev

MR/PR流程

一、什么是MR/PR？

MR：Merge Request(合并请求)，PR:Pull Request（拉取请求）简单来说它们是同一个东西，只是名字不同。

PR 是 GitHub 的叫法，MR是 GitLab 的叫法。 如果非要说区别，PR偏向“请来拉”，MR偏向“请去合”。

作用：

• 开发人员请求：
• 把自己的代码
• 合并到目标分支

例如：你的功能 feature/order-export

开发完成。

不能直接：

feature/order-export ↓ dev

而是：

提交MR：

feature/order-export ↓ dev

然后：

由其他人审核。

二、为什么需要MR？

如果没有MR：

流程：

张三写代码 ↓ 直接 merge dev ↓ 测试 ↓ 上线

问题：

没人知道：

• 改了什么
• 为什么改
• 有没有风险
• 有没有隐藏bug

有 MR：

流程：

开发人员 ↓ 提交 MR ↓ Code Review ↓ 审核通过 ↓ merge

代码进入主分支前：

必须经过检查。

三、MR完整流程

场景：

开发订单导出功能

分支：

feature/order-export

目标：

dev

Step1：确认代码已经提交

查看状态：

gitstatus

应该：

nothing to commit

查看提交记录：

gitlog--oneline

例如：

a8f321 feat: 新增订单导出功能

Step2：推送远程分支

第一次：

gitpush-uorigin feature/order-export

以后：

gitpush

推送完成：

远程仓库出现：

feature/order-export

Step3：进入Git平台

例如：GitLab进入项目

点击：

Merge requests

点击：

New merge request

Step4：选择源分支和目标分支

Source branch：

选择：

feature/order-export

意思：

我要合并谁？

Target branch：

选择：

dev

意思：

合并到哪里？

最终：

feature/order-export ↓ dev

Step5：填写MR信息

标题：

规范：

类型: 功能描述

例如：

feat: 新增订单导出功能

描述：

建议模板：

## 需求 订单列表增加Excel导出功能 ## 修改内容 1. 新增导出接口 2. 增加Excel生成工具 3. 增加权限校验 ## 测试情况 本地测试通过 ## 影响范围 订单模块 ## 注意事项 无

Step6：指定Reviewer

选择：

Reviewer

例如：

张三 李四

规则：

普通代码：

至少：

1人Review

核心模块：

例如：

• 支付
• 库存
• 权限
• 数据库

至少：

2人Review

Step7：提交MR

点击：

Create merge request

状态：

Open

表示：

等待审核。

Step8：Code Review

审核人员检查：

代码：

• 是否符合规范
• 是否存在bug
• 是否影响其他模块

提出：

Comment：

例如：

这里可能存在空指针风险 建议增加非空判断

开发人员修改：

gitadd.gitcommit-m"fix: 优化订单导出空指针处理"gitpush

MR自动更新。

不需要重新创建。

Step9：审核通过

状态：

Approved

点击：

Merge

最终：

feature/order-export ↓ dev

权限规范

master权限

保护：

Protected Branch

规则：

禁止直接push 禁止删除 禁止强制push 必须MR合并

权限：

Maintainer

才可以：

• 合并master
• 发布版本
• 创建tag

prod权限

规则：

禁止开发直接提交 只能通过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

开发人员拥有权限：

创建 提交 推送 删除

权限模型

分支规范

分支

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-m"feat: 新增订单接口"gitcommit-m"fix: 修复库存计算错误"gitcommit-m"refactor: 重构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问题

例如开发List<Order> list = orderMapper.selectAll();

测试数据1000条没问题。

生产5000万订单。直接数据库压力爆炸

Review会检查：

• 是否分页
• 是否索引
• 是否全表扫描

3、发现事务问题

例如订单支付：

updateOrder();savePayment();updateStock();

没有事务结果订单成功，库存失败。导致数据不一致。

Review会要求：@Transactional

4、发现安全问题

例如接口：

@GetMapping("/user/{id}")

直接查询：

select*from user where id=id

没有权限校验。

如果修改id查看别人信息。

/user/10086

Review发现：权限漏洞。

5、保证代码统一

当团队很多人时：

如果没有Review可能出现：

张三：

try{}catch(Exceptione){}

李四：

throwsException

王五：

Result.error()

最后代码风格混乱。

Review统一：

• 异常处理
• 日志规范
• 命名规范
• 返回结构

6、降低人员风险

如果只有一个人知道代码：

风险：

离职 没人维护

Review让至少两个人了解代码。

Code Review检查清单

Java代码

是否存在空指针 是否合理使用事务 是否存在重复代码 是否存在异常吞掉 日志是否合理 是否有敏感信息打印

数据库

SQL是否走索引 是否存在全表查询 是否需要分页 字段类型是否合理 是否需要事务

性能

是否循环查询数据库 是否N+1问题 是否大量内存加载 是否存在慢接口

安全

参数校验 权限校验 SQL注入 数据越权

MR解决：

代码怎么进入主干

Code Review解决：

进入主干之前有没有质量问题

MR + Code Review不是形式，而是保证项目长期可维护的基础。