Git commit规范
目的
统一团队Git commit日志标准,便于后续查找,代码review,版本发布等。
commit message 的格式
<type>: <description>
格式说明: <type>(必须):代表某次提交的类型,所有的type类型如下
build:修改项目构建系统(例如 glup,webpack,rollup, vite 的配置等)的提交
ci:修改项目继续集成流程(例如 Travis,Jenkins,GitLab CI,DockerFile , Circle等)的提交
docs:文档更新,如README, CHANGELOG等:新增功能
fix:修复bug
perf:优化相关,如提升性能、体验等
refactor:重构代码,既没有新增功能,也没有修复 bug
style:不影响程序逻辑的代码修改(修改空白字符,格式缩进、补全缺失的分号等)
test:新增测试用例或是更新现有测试
revert:回滚某个更早之前的提交
chore:其他类型,如改变构建流程、或者增加依赖库、工具等
feat:新增功能相关
<description>(必须): 描述简要描述本次改动,概述就好了
注意点:
<type>后加空格
- 用双引号
- [optional scope] 里内容用
()
示例
Good 正确
good
# 增加一个的导出功能
git commit -m "feat: 增加预测用户列表导出功能"
# 修改了翻页bug
git commit -m "fix: 修改了预测用户翻页bug"
# 优化某某功能
git commit -m "perf: 优化了预测用户接口响应太慢"
# 修改了xx处缺少分号问题
git commit -m "style: 修改xx处缺少分号问题"
Bad 不建议的
# 增加一个的导出功能
git commit -m "update"
# 修改了翻页bug
git commit -m "bug fixed"
# 优化某某功能
git commit -m "update"
# 修改了xx处缺少分号问题
git commit -m "update"
不要写update 写清楚改了什么
不要写update 写清楚改了什么
不要写update 写清楚改了什么
不使用工具校验话,团队各成员要自觉遵循规范。
使用工具校验commit是否符合规范
和 ESLint 一样的是,commitlint 自身只提供了检测的功能和一些最基础的规则。使用者需要根据这些规则配置出自己的规范。
- 安装
npm install -D @commitlint/cli @commitlint/config-conventional
- 生成配置文件
commitlint.config.js
项目根目录下执行:
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
- 在
commitlint.config.js制定提交message规范:
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [2, 'always', [
'build', 'ci', 'docs', 'feat', 'fix', 'perf', 'style', 'refactor',
'test', 'revert', 'chore',
]],
'subject-full-stop': [0, 'never'],
'subject-case': [0, 'never']
}
};
- 检验
commit message的最佳方式是结合git hook,所以需要配合Husky, 可以在每次 commit 时执行 commitlint 检查我们输入的 message,若是校验不通过,则不提交。
- husky介绍:它继承了Git下所有的钩子,在触发钩子的时候,husky可以阻止不合法的
commit,push等。
- 安装
npm install husky -D
- 在跟目录下新增
.huskyrc脚本文件:
{
"skipCI": false,
"hooks": {
"commit-msg": "commitlint -e $HUSKY_GIT_PARAMS",
"pre-commit": "make eslint"
}
}
现在,git commit的时候会触发commlint, 若是不规范,则会提示错误。
如果commit 钩子不生效
- 如果使用的cnpm, 请换npm 或 yarn 换源重新安装依赖之后再次尝试