「这是我参与2022首次更文挑战的第2天，活动详情查看：2022首次更文挑战」。
前言
小凌最近在查找以前提交的代码时，遇到了困难。
大家在日常开发中是否有遇到过这样的提交备注呢？在当时可能为了图方便只是简单的文字描述，或者直接不填写。在短期看来的确是方便了我们快速提交，但是为我们之后维护带来了很大的困难。
接下来我们就来学习如何比较规范地写出commits。
Git Hooks
什么是Git Hooks
如同其他许多的版本控制系统一样, Git也具有在特定事件发生之前或之后执行特定脚本代码功能(就好像监听事件、触发器之类的东西)。Git Hooks就是那些在Git执行特定事任(如commit、 push、receive等) 后触发运行的脚本,hook是可以放置在hook目录中的程序，可在git执行的某些 点触发动作。没有设置可执行位的hook将被忽略。
Git Hooks 能做什么
Git Hooks是定制化的脚本程序，所以它实现的功能与相应的git动作相关，如下几个简单例子:
1.多人开发代码的情况下代码语法、规范强制统一。
2.commit 、message格式化、检查是否符合规范。
3.在特定情况下，可以对测试用例进行检测。
4.服务器上代码有更新的时候可以通知所有开发成员。
5.代码提交后对项目自动打包。
等等...
Git Hooks生命周期
我们可以在以下目录下看到：
{yourLocalUrl}\.git\hooks
hooks目录钟存放了很多sample文件，这里面的每一个sample，其实就是每一个git钩子。
Husky + commitlint
Husky是Git Hooks的一个工具(官网地址)。
安装配置
1.安装husky
yarn add @commitlint/config-conventional @commitlint/cli husky -D
2.package.json增加
package.json
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}
3.根目录增加文件commitlint.config.js
commitlint.config.js
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [
2,
'always',
[
'bug', // 此项特别针对bug号，用于向测试反馈bug列表的bug修改情况
'feature', // 新功能（feature）
'fix', // 修补bug
'docs', // 文档（documentation）
'style', // 格式（不影响代码运行的变动）
'refactor', // 重构（即不是新增功能，也不是修改bug的代码变动）
'test', // 增加测试
'chore', // 构建过程或辅助工具的变动
'revert', // feat(pencil): add ‘graphiteWidth’ option (撤销之前的commit)
'merge' // 合并分支， 例如： merge（前端页面）： feature-xxxx修改线程地址
]
]
}}
测试提交
不符合规范的提示git commit -m 'test'
规范的提示git commit -m "fix: 修改test.cls"
如此我们就能规范化去提交我们的修改信息啦。
各个提交类型的意义
'feat', // 新功能
'upd', // 修改
'del', // 删除
'fix', // bug修复
'test', // 单元测试
'perf', // 性能优化
'docs', // 文档更新
'style', // 样式变动
'refactor', // 功能重构
'revert', // 回滚某个更早之前的提交
'package', // 创建包
最后要说的
大家有什么问题欢迎评论哦~如果你觉得小凌写的不错那么请给小凌一个赞呗。你的支持是我前进下去的动力🙂
