团队 Git 开发规范：分支、Commit、Merge Request 与 CI/CD 流程详解

在团队开发中，Git 不只是一个“代码上传工具”。

如果每个人都按照自己的习惯提交代码，很快就会出现很多问题：

fix
update
修改了一下
123
测试
最终版本
最终版本2
真的最终版本

等到线上出了问题，再去翻 Git 记录时，基本无法快速判断：

这次提交改了什么？
为什么修改？
哪个提交引入了问题？
这个分支是从哪里拉出来的？
代码有没有经过 Code Review？
哪一版最终发布到了线上？

所以，一个团队必须有一套统一的 Git 规范。

本文主要介绍四部分内容：

1. Git Commit 提交规范
2. Git 分支规范
3. Merge Request / Code Review 流程
4. CI/CD 发布流程

最终目标其实非常简单：

让每一次代码修改，都能够被追踪、被理解、被审核、被安全发布。

一、为什么一定要有 Git 规范？

假设一个项目有 10 个开发人员。

如果每个人提交代码都是：

update

fix

修改代码

修复问题

半年以后查看日志：

git log

看到：

fix
update
fix
测试
修改
update

你根本不知道这些提交做了什么。

但是如果提交记录是：

feat/multi_merchant: 支持多商户下单

bugfix/user: 修复用户手机号为空导致登录失败

perf/user_login: 优化用户登录查询性能

hotfix/create_order: 修复线上重复创建订单问题

是不是马上清晰很多？

所以 Git 规范最大的价值，就是：

让代码修改本身具有可读性。

二、Git Commit 提交规范

团队提交代码时，需要根据本次修改的类型选择对应的 Commit 类型。

常见类型如下：

类型	含义	示例
feat	新功能	feat/multi_merchant
bugfix	普通 Bug 修复	bugfix/user
hotfix	紧急线上问题修复	hotfix/create_order
perf	性能优化	perf/user_login
style	格式、代码清理等不影响业务的修改	style/log_print
refactor	代码重构	refactor/user
test	测试相关	test/user
docs	文档、注释修改	docs/user
chore	依赖、脚手架、配置等琐事	chore/dependency

下面分别说明。

三、feat：开发新功能

feat 表示：

Feature，新功能。

例如我们要开发：

多商户功能

那么可以写：

feat/multi_merchant

Commit 信息建议写完整：

feat/multi_merchant: 支持多商户下单功能

或者：

feat/multi_merchant: 新增商户切换及订单归属逻辑

不要只写：

feat

因为虽然知道是新功能，但不知道：

到底是什么新功能。

四、bugfix：修复普通 Bug

bugfix 用于普通功能问题修复。

例如：

用户模块存在 Bug：

用户手机号为空时登录报错

可以提交：

bugfix/user: 修复手机号为空导致登录失败的问题

如果是订单模块：

bugfix/order: 修复取消订单后库存未释放的问题

这里非常重要：

Commit 信息不要只写：

bugfix/user

最好进一步说明：

bugfix/user: 修复用户信息为空导致空指针异常

因为真正有价值的信息，是：

修复了什么问题。

五、hotfix：线上紧急 Bug 修复

hotfix 通常用于：

线上严重问题的紧急修复。

例如：

线上订单出现重复创建

这种问题已经影响真实用户或真实业务，就应该使用：

hotfix/create_order: 修复订单重复创建问题

例如：

hotfix/payment: 修复支付回调重复处理导致订单金额异常

bugfix 和 hotfix 的区别可以简单理解成：

bugfix
普通 Bug

hotfix
线上紧急 Bug

例如：

测试环境发现按钮无法点击

→ bugfix

而：

线上用户无法支付

→ hotfix

所以 hotfix 一般优先级非常高。

六、perf：性能优化

perf 表示：

Performance，性能优化。

注意规范应该写成：

perf

而不是：

pref

例如用户登录接口比较慢。

原来：

500ms

优化以后：

80ms

那么可以提交：

perf/user_login: 优化用户登录接口查询性能

例如：

perf/order_query: 优化订单列表分页查询

常见性能优化包括：

SQL 优化

索引优化

缓存优化

批量查询

减少数据库访问

减少远程调用

算法优化

这些都可以使用：

perf

七、style：代码格式和非业务修改

style 很容易被误解。

它不是：

修改前端 CSS 样式。

在 Git Commit 规范中，style 更多表示：

不影响业务逻辑的代码调整。

例如：

删除无用注释

调整代码格式

删除无用 import

调整空格

日志格式调整

例如：

style/log_print: 统一订单模块日志输出格式

或者：

style/user: 删除用户模块无用注释

特点就是：

代码看起来变了，但是业务行为没有发生改变。

八、refactor：代码重构

refactor 表示：

重构代码，但是不改变原有业务功能。

例如以前用户注册写成：

public void register() {
    // 200 行代码
}

后来拆成：

validateUser();

createUser();

saveUser();

sendRegisterMessage();

功能没有变化。

只是代码结构变好了。

可以提交：

refactor/user: 重构用户注册逻辑

再例如：

refactor/order: 拆分订单创建流程

需要注意：

修 Bug

不要写：

refactor

应该写：

bugfix

因为：

refactor

原则上表达的是：

代码结构变化，但是业务行为不变化。

九、test：测试相关修改

test 用于：

单元测试

集成测试

测试数据

测试代码

测试用例

例如：

test/user: 补充用户登录单元测试

或者：

test/order: 增加订单创建异常场景测试

如果修改的是正常业务代码，就不应该使用：

test

十、docs：文档和注释修改

docs 表示：

Documentation。

用于：

README

接口文档

技术文档

业务文档

代码注释

例如：

docs/user: 补充用户登录接口说明

或者：

docs/order: 完善订单状态说明

十一、chore：依赖、配置和日常维护

chore 通常表示：

不直接涉及业务功能的工程维护。

例如：

升级 Spring Boot

升级 Maven 依赖

修改脚手架

调整构建脚本

修改代码扫描配置

更新 Docker 配置

例如：

chore/dependency: 升级 hutool 版本

或者：

chore/maven: 调整 Maven 打包配置

十二、完整 Commit 示例

一个比较好的 Commit 应该做到：

类型 / 模块 : 做了什么事情

例如：

feat/multi_merchant: 支持多商户下单

bugfix/user: 修复手机号为空导致登录失败

hotfix/create_order: 修复线上订单重复创建问题

perf/user_login: 优化用户登录 SQL 查询

style/log_print: 统一日志打印格式

refactor/user: 重构用户注册流程

test/order: 补充订单创建单元测试

docs/user: 补充用户接口文档

chore/dependency: 升级 Spring Boot 依赖

这样以后执行：

git log

看到的历史记录会非常清晰。

十三、不推荐的 Commit 写法

以下 Commit 应尽量避免：

fix

update

修改

优化

测试

代码修改

解决问题

因为这些信息没有上下文。

例如：

fix

到底修了什么？

不知道。

而：

bugfix/user: 修复用户昵称过长导致保存失败

信息就非常完整。

所以一个好的 Commit 至少应该回答两个问题：

1. 这是什么类型的修改？

2. 这次具体修改了什么？

十四、Git 分支规范

除了 Commit，团队还需要统一：

分支从哪里拉取。

团队主要存在以下几个核心分支：

分支	是否保护	作用
test	是	测试环境分支
pre	是	预发布环境分支
prod	是	线上生产环境分支
master	是	线上代码存档，与 prod 保持同步
其他开发分支	否	日常开发使用

可以简单理解：

开发分支
   ↓
test
   ↓
pre
   ↓
prod
   ↓
master

不同公司的发布流程可能略有不同，但是环境含义基本就是：

test = 测试环境

pre = 预发布环境

prod = 正式生产环境

master = 线上稳定代码存档

十五、已上线项目从哪里拉分支？

如果系统：

已经上线生产环境。

新的开发分支应该基于：

prod

或者团队规定的：

master

拉取最新代码。

例如：

git checkout prod

git pull

然后创建开发分支：

git checkout -b feat/multi_merchant

为什么不能随便从 test 拉？

因为 test 里面可能存在：

正在测试但尚未上线的代码

如果你从 test 拉新功能：

test
 ↓
你的开发分支

就有可能把别人还没上线的功能一起带进去。

所以对于已经上线的系统：

应该从当前线上稳定代码拉取新的开发分支。

也就是：

prod / master

十六、未上线项目从哪里拉分支？

如果项目还处于：

开发阶段

还没有正式上线。

那么统一从：

test

拉取最新代码。

例如：

git checkout test

git pull

git checkout -b feat/user_login

因为此时 test 可以认为：

当前项目最新的集成开发基线。

十七、开发分支如何命名？

建议开发分支与 Commit 类型保持一致。

例如：

新功能：

feat/multi_merchant

Bug：

bugfix/user_login

线上紧急修复：

hotfix/create_order

性能优化：

perf/order_query

重构：

refactor/payment

文档：

docs/api

这样看到分支名称，就知道这个分支在干什么。

不要出现：

zhangsan

test2

new

aaa

dev123

临时

因为其他人完全不知道分支用途。

十八、一个标准的新功能开发流程

假设现在需要开发：

多商户功能

并且项目已经上线。

第一步：

切换线上分支。

git checkout prod

第二步：

拉取最新代码。

git pull

第三步：

创建开发分支。

git checkout -b feat/multi_merchant

然后开始开发。

十九、开发完成后提交代码

首先查看修改：

git status

然后添加文件：

git add .

提交：

git commit -m "feat/multi_merchant: 支持多商户下单功能"

然后 Push 到远程仓库：

git push origin feat/multi_merchant

此时只是：

把自己的开发分支上传到了远程仓库。

并不代表代码已经进入 test。

二十、为什么不能直接 Push 到 test？

test、pre、prod、master 都属于：

公共环境分支。

如果所有开发人员都能：

git push origin test

那么很容易出现：

未经审核的代码进入测试环境

错误代码覆盖别人代码

冲突没有处理好

线上 Bug 被意外带入

错误功能直接进入公共分支

所以这些核心分支应该设置：

Protected Branch

也就是：

受保护分支。

开发人员正常情况下不直接 Push。

而是走：

Merge Request。

二十一、什么是 Merge Request？

Merge Request 简称：

MR

GitHub 中通常叫：

Pull Request

也就是：

PR

本质上是一样的：

请求把一个分支的代码合并到另一个分支。

例如：

feat/multi_merchant
        ↓
      test

开发完成以后，在远程 Git 平台发起：

Source Branch:
feat/multi_merchant

Target Branch:
test

也就是：

开发分支
   ↓
Merge Request
   ↓
test

二十二、Merge Request 发起以后做什么？

发起 MR 后：

不要直接自己合并。

需要把 MR 链接发送到团队群。

并：

@技术负责人

例如：

多商户功能已开发完成。

MR：
xxxxxx

麻烦帮忙 CR 一下。
@技术负责人

这里的 CR 指：

Code Review

代码审查。

二十三、什么是 Code Review？

Code Review 简称：

CR

它不是简单看一下：

代码能不能编译。

而是检查：

代码逻辑是否正确

是否可能有 Bug

代码规范是否符合要求

是否存在性能问题

SQL 是否合理

是否存在安全问题

异常是否处理

日志是否完整

有没有重复代码

设计是否合理

例如看到：

for (User user : users) {
    userMapper.selectById(user.getId());
}

负责人可能会指出：

这里存在 N+1 查询问题。

要求改成：

批量查询

开发人员修改以后再次 Push：

git add .

git commit -m "perf/user_query: 优化用户批量查询逻辑"

git push

MR 会自动更新。

然后继续 CR。

二十四、为什么一定要 Code Review？

因为程序员写自己的代码时，很容易出现：

自己看自己的代码，看不出自己的问题。

Code Review 相当于：

开发者
   ↓
第一道检查

技术负责人 / Reviewer
   ↓
第二道检查

测试
   ↓
第三道检查

比直接：

开发完成
   ↓
上线

安全得多。

尤其是：

支付

订单

库存

金额

权限

数据删除

这种核心业务代码。

必须严格 CR。

二十五、CR 通过以后才能合并

当技术负责人确认代码没有明显问题以后：

Approve

才允许执行：

Merge

例如：

feat/multi_merchant
        ↓
      Merge
        ↓
       test

此时开发代码才真正进入：

test

二十六、Merge 成功后 CI/CD 自动开始工作

代码成功合并到 test 后，可以通过 CI/CD 自动完成：

拉取代码
   ↓
编译
   ↓
单元测试
   ↓
代码扫描
   ↓
打包
   ↓
构建镜像
   ↓
部署
   ↓
测试环境

开发人员不应该每次都手动：

登录服务器

git pull

mvn package

java -jar

杀进程

重新启动

这种方式：

风险高，而且不可追踪。

现代开发流程一般通过：

Git
+
CI/CD

自动完成。

二十七、完整提测流程

整个流程可以理解为：

从基准分支拉代码
        ↓
创建开发分支
        ↓
开发功能
        ↓
Git Commit
        ↓
Push 开发分支
        ↓
创建 Merge Request
        ↓
发送群里
        ↓
@技术负责人
        ↓
Code Review
        ↓
修改问题
        ↓
Review 通过
        ↓
Merge 到 test
        ↓
CI/CD
        ↓
自动构建
        ↓
自动部署
        ↓
测试环境
        ↓
测试人员测试

这就是一个比较完整的团队 Git 开发流程。

二十八、Bug 修复流程举例

假设测试人员发现：

用户修改头像后头像没有立即刷新。

创建分支：

git checkout test

git pull

git checkout -b bugfix/user_avatar

修改完成：

git add .

提交：

git commit -m "bugfix/user_avatar: 修复用户头像更新后缓存未刷新问题"

Push：

git push origin bugfix/user_avatar

然后创建：

bugfix/user_avatar
        ↓
       test

的 MR。

技术负责人 CR。

通过以后 Merge。

CI/CD 自动部署测试环境。

测试人员验证 Bug。

二十九、线上 Hotfix 流程举例

线上突然发现：

创建订单可能重复扣库存。

这是严重线上问题。

此时不能从：

test

拉代码。

因为 test 里面可能还有：

没有上线的新功能。

应该从当前生产代码：

prod

拉。

例如：

git checkout prod

git pull

git checkout -b hotfix/create_order

修改：

重复扣库存问题

Commit：

git commit -m "hotfix/create_order: 修复重复提交导致库存重复扣减"

然后按照线上 Hotfix 发布流程进行 Review 和发布。

核心原则是：

修线上 Bug，必须基于线上代码修改。

否则你可能本来只想修一个 Bug，却顺便把 test 中十几个尚未上线的功能全部带到生产。

这是非常危险的。

三十、为什么 master 要同步 prod？

团队约定：

prod

表示：

真实线上运行代码。

而：

master

用于：

线上稳定代码归档。

所以应该保持：

prod
   ↓
master

实时或者按发布流程同步。

这样：

master

永远代表：

当前稳定生产版本。

实际采用 prod 作为唯一生产主线，还是采用 master 作为生产主线，各团队可以不同。

最重要的是：

团队必须统一，不能一半人认为 prod 是线上，一半人认为 master 是线上。

三十一、分支关系总结

可以简单记成：

                         ┌─────────────┐
                         │ 开发分支     │
                         │ feat/*      │
                         │ bugfix/*    │
                         │ refactor/*  │
                         └──────┬──────┘
                                │
                                ↓
                              test
                                │
                                ↓
                               pre
                                │
                                ↓
                              prod
                                │
                                ↓
                             master

其中：

test
pre
prod
master

应该受到保护。

开发人员主要操作：

feat/*
bugfix/*
hotfix/*
perf/*
refactor/*

三十二、团队开发最容易犯的错误

错误一：直接改 test

例如：

git checkout test

然后：

直接写代码。

不推荐。

应该：

test / prod
     ↓
创建开发分支
     ↓
开发

错误二：直接 Push test

例如：

git push origin test

应该禁止。

应该走：

开发分支
   ↓
MR
   ↓
Code Review
   ↓
test

错误三：Commit 写得太随便

不要：

fix

应该：

bugfix/user: 修复用户手机号为空导致登录失败

错误四：修线上 Bug 却从 test 拉代码

这是一个非常危险的问题。

错误：

test
 ↓
hotfix
 ↓
prod

因为 test 可能包含尚未上线的代码。

正确：

prod
 ↓
hotfix
 ↓
prod

错误五：MR 没有 CR 就直接合并

Merge Request 最大的价值之一就是：

Code Review

如果：

创建 MR
 ↓
自己 Merge

那 MR 很大程度上就失去了意义。

三十三、推荐团队最终执行规范

可以把整个规范浓缩成几条：

1. 所有开发必须建立独立分支

禁止直接在：

test
pre
prod
master

进行业务开发。

2. 已上线项目基于生产稳定分支创建开发分支

一般：

prod / master

具体按照团队约定。

3. 未上线项目基于 test 创建开发分支

例如：

test
 ↓
feat/*

4. Commit 必须有明确语义

例如：

feat/order: 支持批量创建订单

bugfix/user: 修复用户昵称为空导致保存失败

5. 开发完成先 Push 自己的分支

例如：

git push origin feat/multi_merchant

6. 需要提测时创建 MR

例如：

feat/multi_merchant
        ↓
       test

7. MR 链接发团队群并 @负责人

由负责人：

Code Review

8. CR 通过以后才能 Merge

禁止未经 Review 直接进入公共分支。

9. Merge 后通过 CI/CD 自动部署

例如：

Merge test
   ↓
Pipeline
   ↓
Build
   ↓
Deploy
   ↓
测试环境

三十四、最终记忆版

如果是刚加入团队的新人，不想一次记太多，可以先记住下面这套流程：

先拉最新代码
      ↓
创建自己的开发分支
      ↓
写代码
      ↓
规范 Commit
      ↓
Push 自己的分支
      ↓
提交 MR
      ↓
把 MR 发群里
      ↓
@负责人 CR
      ↓
CR 通过
      ↓
Merge
      ↓
CI/CD 自动部署

Commit 类型记住：

feat      新功能

bugfix    普通 Bug

hotfix    线上紧急 Bug

perf      性能优化

style     格式、无业务影响修改

refactor  重构

test      测试

docs      文档

chore     依赖、配置等杂项

环境分支记住：

test
测试环境

pre
预发布环境

prod
生产环境

master
生产稳定代码存档

开发过程中最重要的一个原则就是：

不直接修改公共分支，不直接把未经审核的代码推到公共环境。

Git 规范看起来只是规定了一些分支名称和 Commit 格式，但它真正解决的是：

谁改了代码

为什么改

改了什么

代码有没有被审核

什么时候进入测试

什么时候进入生产

线上版本到底是哪一份代码

一个成熟团队的 Git 流程，最终追求的不是“看起来专业”，而是：

每一次代码变更，都有来源、有记录、有审核、有发布链路，并且出了问题能够快速定位和回滚。

这才是 Git 规范真正的价值。