最近公司的前端团队分了组,我根据兴趣加入了基础设施建设组,负责做一些方便和规范开发的东西。第一个产出是增加了Git的提交规范,之前参与开源项目时接触到的,感觉很有意思,也很实际,用得到。
参考资料: 阮一峰-Commit message 和 Change log 编写指南
Git提交规范
意义及现状
在开发过程中,Git每次提交代码,都需要写Commit message(提交说明),规范的Commit message有很多好处:
- 方便快速浏览查找,回溯之前的工作内容
- 可以直接从commit 生成Change log(发布时用于说明版本差异)
目前我们并没有对commit message进行规范,造成以下麻烦:
- 每个人风格不同,格式凌乱,查看很不方便
- 部分commit没有填写message,事后难以得知对应修改的作用
规范Commit message不仅能解决上述问题,而且基本没有副作用和学习成本,应该尽早加上。
规范方式
为了实现规范,我们使用commitlint和husky 来进行提交检查,当执行git commit
时会在对应的git钩子上做校验,只有符合格式的Commit message才能提交成功。
为了方便使用,增加了commitizen支持,使用cz-customizable进行配置。支持使用git cz
替代git commit
。
有兴趣的小伙伴可以查阅相关文档。
PS: 之后如果要推行代码规范,也可以使用husky来在其他的Git钩子(如pre-push等)上进行eslint等校验。
Commit message 格式
为了方便使用,我们避免了过于复杂的规定,格式较为简单且不限制中英文:
<type>(<scope>): <subject>
// 注意冒号 : 后有空格
// 如 feat(miniprogram): 增加了小程序模板消息相关功能
scope选填表示commit的作用范围,如数据层、视图层,也可以是目录名称
subject必填用于对commit进行简短的描述
type必填表示提交类型,值有以下几种:
- feat - 新功能 feature
- fix - 修复 bug
- docs - 文档注释
- style - 代码格式(不影响代码运行的变动)
- refactor - 重构、优化(既不增加新功能,也不是修复bug)
- perf - 性能优化
- test - 增加测试
- chore - 构建过程或辅助工具的变动
- revert - 回退
- build - 打包
如何加入项目
// commitlint
// 项目目录下安装
npm i commitlint --save-dev
npm i @commitlint/config-conventional --save-dev
touch commitlint.config.js
// commitlint.config.js
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
// type 类型定义
'type-enum': [2, 'always', [
"feat", // 新功能 fea