@[toc]
一、背景
- Git每次提交代码都需要写commit message,否则就不允许提交。一般来说,commit message应该清晰明了,说明本次提交的目的,具体做了什么操作……但是在日常开发中,大家的commit message千奇百怪,中英文混合使用、fix bug等各种笼统的message司空见怪,这就导致后续代码维护成本特别大,有时自己都不知道自己的fix修的是什么bug。
- 而近期,我们团队内有好几个大需求都需要多个研发同学all in一个开发分支,但是在开发过程中我发现很多研发同学提交的commit信息“五花八门”,这就导致在定位问题时不知道对方或者自己的每笔提交是什么含义,无法快速定位问题。
- 基于以上这些问题,我们希望通过某种方式来约束用户的git commit message,让规范更好的服务于质量,提高大家的研发效率。一旦约束了commit message,意味着我们将慎重的进行每一次提交,不能再一股脑的把各种各样的改动都放在一个git commit里面,这样一来整个代码改动的历史也将更加清晰。
二、一般的commit message格式
2.1 文字版
注:如果不想看长篇文字的,可以直接看下面的流程图
对于一般的commit约束规范为:
- 检查提交者的邮箱 (user.email)
- 它会读取你本地 Git 配置的 user.email。
- 规则:
- 邮箱不能为空。
- 邮箱必须以 @xxx(公司名后缀).com 或 @xxx.net 结尾。
- 如果不满足,提交会被阻止,并提示你如何通过 git config 命令设置正确的邮箱。
- 检查提交者的姓名 (user.name)
- 它会读取你本地 Git 配置的 user.name。
- 规则:
- 姓名不能为空。
- 如果不满足,提交会被阻止,并建议你设置为中文名。
- 检查提交信息的编码
- 它会读取你写的提交信息文件。
- 规则:
- 提交信息必须是 UTF-8 编码。
- 如果不满足,提交会被阻止。
- 检查提交信息的格式 (核心功能)
- 这是这个hook最重要的检查。
- 规则: 提交信息的第一行必须以下列前缀之一开头:
- feat: (用于提交新功能)
- fix: (用于修复 bug)
- docs: (用于修改文档)
- style: (用于代码格式调整,不影响功能)
- refactor: (用于重构代码)
- test: (用于增加或修改测试)
- chore: (用于构建过程或辅助工具的变动)
- 例外情况: 它也允许以下 Git 自动生成的提交信息开头:
- Revert (当你执行 git revert 时)
- Merge branch (当你执行 git merge 时)
- cherry pick (当你执行 git cherry-pick 时)
- 如果不满足以上任何一种格式,提交会被阻止,并向你展示所有允许的格式和它们的含义,同时提供一个链接让你查看更详细的规范。
这里展开对具体格式提交格式讲讲
格式:
: - type(必填):用于说明git commit的类别,只允许使用下面的标识。
1
2
3
4
5
6
7
8
9
10
11* feat:新功能(feature)
* fix:修复bug
* docs:文档更新
* style:格式更新(修改空白字符,格式缩进,补全缺失的分号等,没有改变代码逻辑)
* refactor:重构代码(既没有新增功能,也没有修复 bug)
* perf:性能, 体验优化
* test:新增测试用例或是更新现有测试
* revert:回滚到上一个版本。
* xxxff:代码合并。
* sync:同步主线或分支的Bug。
* build:主要目的是修改项目构建系统(例如 glup,webpack,rollup 的配置等)的提交- subject(必填):subject是commit目的的简短描述。建议使用中文,结尾不加句号或其他标点符号。

示例:
- fix: 修改内存泄漏问题
- feat: 用户查询接口开发
2.2 流程图版
1 | graph TD |
三、不规范commit示例
在旧规范下依旧存在较多不规范的commit case,其中有些case是可以通过在提交前进行强制拦截的。
| case | 问题 | 建议 |
|---|---|---|
| feat: update data for search | 全英文描述 | 尽量使用中文 eg:更新RN相关的资源 |
| feat: 更新登陆样式&修改进入页面的链路 | 多处功能改动参杂着bug作为一笔提交 | 每个 commit 只完善一个功能/修复一个问题,保证提交commit的原子性 |
| fix: ui样式修复 | 描述过于简单,无法根据commit知晓修改的功能 | 用简洁的语言描述具体的工作 eg: fix: 问一问落地页输入框样式修复 feat: DSL升级以支持Kitt引擎 |
| feat: 提高效率 feat: 提高效率 |
多次重复提交同一条commit | 不要在同一个分支下提交重复的commit信息,如果解决的是一类问题,建议squash成一笔提交 |
| feat: gjfahekfhsarjgjkajrgkntkzghndkztnbhknbhkgjdnthkjgnkdnhjk | 提交的字符过长 | 建议subject的字符数不超过72个。 (因为Git 工具通常在 72 字符处自动折行,超过会导致信息被截断,影响阅读。) |
| fix: 修复了一个线上问题 | 描述信息subject的首尾存在多余的空格 | subject的首部至多有一个空格,尾部不应该含有空格 |
| feat: 你好啊! | 末尾有特殊字符,比如?。等 | commit信息末尾不应该有特殊字符 |
四、制定新规范
4.1 强制约束类
- 格式:
<type>:[最多一个空格]<subject>[无特殊字符,无空格]
在原有规范的基础上,新增规范如下:注⚠️:如果确实需要紧急合入,则可用
--force命令,即git commit -m "feat: 这是一次紧急提交,忽略新增规范的约束 --force"

新规范对应的流程图如下:
图太大了,请将手机/电脑旋转90度“食用”

4.2 建议提倡类
- 原子性提交:每个 commit 只完善一个功能/修复一个问题
- 功能完整性:每个 commit 都应该是可编译、可运行的
- 逻辑分离:重构、优化和功能开发分开提交
- 语义明确:commit描述要清晰、简洁明了,尽量使用中文
五、hook脚本安装
- 创建hook脚本
已亲测无问题,对应的是第四章节的规范
1 |
|
- 修改将 buildsystem/githooks 目录视为存放钩子脚本的地方
1
git config core.hooksPath buildsystem/githooks
- 赋予执行权限
1
chmod +x buildsystem/githooks/commit-msg
- 将文件权限的变更添加到暂存区
1
git add buildsystem/githooks/commit-msg
- 进行代码commit

