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 - 打包