问题来源于知乎的一个讨论:如何写好 Git commit log?https://www.zhihu.com/question/21209619/answer/257574960
有个高赞的答案:
这种东西,当然要借助工具了,才能够写得即规范,又格式化,还能够支持后续分析。
目前比较建议的是,使用终端工具 commitizen/cz-cli + commitizen/cz-conventional-changelog + conventional-changelog/standard-version 一步解决提交信息和版本发布。
甚至,如果想更狠一点,在持续集成里面加入 marionebl/commitlint 检查 commit 信息是否符合规范,也不是不可以。
这个工具确实很好用,之前团队的提交规范是口头约定,这种模式显然不够智能,自觉遵循口头规范这个确实很难做到,而这个工具显然提供了便利。
使用方法很简单,可以在全局安装或者项目级安装,我选择根据项目来,这样就算别的同学下载到代码依然可以跑起来。
- 安装模块:
npm install -D commitizen cz-conventional-changelog
- 配置package.json
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"commit": "git-cz"
},
"config": {
"commitizen": {
"path": "node_modules/cz-conventional-changelog"
}
}
最后提交的时候直接使用 npm run commit
命令即可。
- 使用
git add .
npm run commit
git push
根据命令提示一步步输入 message 即可。
如下是提交时候的提示信息:
- type: commit 的类型
- feat: 新特性
- fix: 修改问题
- refactor: 代码重构
- docs: 文档修改
- style: 代码格式修改, 注意不是 css 修改
- test: 测试用例修改
- chore: 其他修改, 比如构建流程, 依赖管理.
- scope: commit 影响的范围, 比如: route, component, utils, build...
- subject: commit 的概述, 建议符合 50/72 formatting
- body: commit 具体修改内容, 可以分为多行, 建议符合 50/72 formatting
- footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.
提交信息分类总结的很完整,推荐使用这种方式。
网友评论