【Git】Git commit message的自我修养(规范化)
Git commit 的介绍从git官网我们可以知道Git commit作用是记录对仓库的修改在日常开发中,使用Git命令最多的应该就是Git commit ,然而书写规范的commit message能够提高开发人员的代码维护升级效率,在能快速方便排查问题。那么commit message的规范就十分重要了Git commit message的规范目前使用比较多的规范是Ang...
目录
Commitizen工具:提供符合规范的git commit 规范
Git commit 的介绍
从git官网我们可以知道Git commit作用是记录对仓库的修改
在日常开发中,使用Git命令最多的应该就是Git commit ,然而书写规范的commit message能够提高开发人员的代码维护升级效率,在能快速方便排查问题。那么commit message的规范就十分重要了
Git commit message的规范
目前使用比较多的规范是Angular规范,阿里、滴滴也有在使用。
从Angular的的文档可以看到commit message的格式
<type>(<scope>): <subject> <body> // 主体,对提交进行详细的描述<footer>
由文档可知有三部分,分别为
- Header 消息头,type:包含类型(必填),scope:作用域(影响的模块/文件)(选填), subject:简短描述(必填)
- Body 主体,填写此次更改的详细描述
- Footer,在出现以下两种情况时需要填写
- Breaking changes:是否出现重大改变,例如版本升级、接口升级、架构调整、项目分离迁移合并等
- affect issues:此次提交是否影响到某个问题
type类型有以下几种:
- feat: 新的功能(feature)
- fix:Bug问题修复
- improvement: 对现有功能的改进
- docs :文档改动(eg:md文件)
- style: 代码格式的变动(注:不是样式,是指代码的空格、缩进、换行、标点符号等)
- refactor: 重构
- perf: 性能优化(performance)
- test: 测试文件更新
- build: 构建系统或者包依赖更新(eg: gulp、npm、broccoli)
- ci: CL配置,脚本文件等更新(eg:Travis持续集成服务、)
- chore: 非src或者测试文件的更新
- revert: commit 回滚
Commitizen工具:提供符合规范的git commit 规范
Commitizen是一款能生成标准规范的commit信息工具。
使用环境:node > 6.0
尽管该工具兼容低版本node,但该工具是在node10.x和12.x的环境下测试的,所以使用环境最好是大于node6.0
Commitizen安装
npm install -g commitizen
或本地安装
npm install -save-dev commitizen
cz-conventional-changelog 适配器安装(可用脚本生成commit文档)
npm install -g cz-conventional-changelog
上一步安装完后,需要在根目录添加配置文件.zcrc
{ "path": "cz-conventional-changelog" }
接下来执行commitizen命令,会自动在package.json中添加相应的配置
// 执行命令
commitizen init cz-conventional-changelog --save-dev --save-exact
或是使用yarn
commitizen init cz-conventional-changelog --yarn --dev --exact
//package.json自动生成如下
"config": {
"commitizen": {
"path": "cz-conventional-changelog"
}
}
完成上述步骤我们就可以在提交代码时用工具生成git commit模板,用git cz 命令 替换 git commit来使用。
由于引入新的依赖,选择build
依次下来填写/选择
- 本次改动的组件或者文件名
- 简短描述(不超过79个字符)
- 详细描述
- 是否出现重大改变
- 此次提交是否影响/修复到某个问题
从gitlab仓库上面的commit记录就可以清楚的看到提交的信息
如果我们git cz 选择了有重大改变(breaking changes),会多一行关于重大改变的描述需要输入
仓库commit上也会多出一行BREAKING CHANGE描述
如果提交的代码涉及到修复issues问题,那么提交时可以选择是否影响到issues问题,此时需要输入issues信息(e.g. "fix #123", "re #123".)
仓库的提交记录就会自动关联上issues问题,点击#1即可跳转issues问题页面。此时只是关联,并不能改变仓库issues问题的状态,如果需要影响到问题的状态,还需要安装配置jira
生成 Change log
如果我们提交的commit都符合Angular格式,执行下列命令则可以在根目录生CHANGELOG.md。生成的文档包含三个模块:feature、bug、breaking change
// 此命令不会覆盖之前的Change log,而是会在CHANGELOG.md头部加上 上次发布到现在的改动
conventional-changelog -p angular -i CHANGELOG.md -s
如果要生成所有的change log,可以执行下列命令
conventional-changelog -p angular -i CHANGELOG.md -w -r 0
为了避免每次都输入那么长的命令行,可以在package.json定义命令
// 生成上次发布到现在的改动
npm run changelog
//生成所有改动
npm run allChangelog
生成的日志文档如下,哪一天修复新增改动了一目了然,还可以直接链接到gitlab仓库对应的commit-id
但是上面有个地方需要注意:在生成changelog日志之前,需要用下面的命令更新一下package.json的版本号,如果不做这一步,会导致每次提交都会带上之前重复的日志
npm version 版本号
git commit 格式校验
有了commit规范就需要有校验,那么格式校验需要用到commitlint、husky
commitlint:用以配置commit message的格式
husky: 是一个git hook的管理工具,实现了大部分的git hook(git命令的钩子)
运行环境:Node >= 8.6.0 和 Git >= 2.13.0.
// commitlint安装
npm install --save-dev @commitlint/{cli,config-conventional}
//创建commitlint配置文件
echo "module.exports = {extends: ['@commitlint/config-angular']};" > commitlint.config.js
//Husky安装
npm install --save-dev husky
//在package.json添加husky配置,与script平级
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}
测试
如果不符合规范的commit提交,commit会被拦截
符合校验的commit message则会被通过提交
目的
- 统一开发团队的commit规范,方便后续代码维护
- 给予其他开发人员提供有效的历史提交信息
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)