git commit 规范工具

commitizen
cz-conventional-changelog
commitlint
husky

1. 全局安装commitizen

npm install -g commitizen
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc

2.全局安装 cz-conventional-changelog

npm install -g  cz-conventional-changelog
# 写配置文件
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc

在安装commitizen,cz-conventional-changelog 之后就已经可以使用git cz 来代替git commit了.如下图

但是,此时你依然可以使用git commit 写一些不符合规范的commit用来提交. 所以我们要对git commit的行为进行限制,不让乱提交

3.项目目录下(git管理的目录下)安装commitlint

npm i -D @commitlint/config-conventional @commitlint/cli

# 写配置文件
echo 'module.exports = {extends: ["@commitlint/config-conventional"]};' > ./commitlint.config.js

4.项目目录安装husky:提供git hook

npm i -D husky

npx husky install

#使用适配commitlint的commit-msg hook
npx husky add .husky/commit-msg 'npx commitlint --edit $1'

在使用husky之后,需要查看commit是否正常生成了

如果不能正常生成Change-Id,则不能push成功

解决办法: 在.husky目录里的commit-msg添加执行git自己的commit-msg来生成Change-Id

if [ -f .git/hooks/commit-msg ]; then
  . ".git/hooks/commit-msg"
fi

至此,就可以约束git commit的提交规范了,养成良好习惯.

5. git cz 字段参考

# 主要type
feat:     增加新功能
fix:      修复bug

# 特殊type
docs:     只改动了文档相关的内容
style:    不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build:    构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert:   执行git revert打印的message

# 暂不使用type
test:     添加测试或者修改现有测试
perf:     提高性能的改动
ci:       与CI（持续集成服务）有关的改动
chore:    不修改src或者test的其余修改，例如构建过程或辅助工具的变动


scope:
scope也为必填项
用于描述改动的范围，格式为项目名/模块名，例如：node-pc/common rrd-h5/activity
而we-sdk不需指定模块名。如果一次commit修改多个模块，建议拆分成多次commit，以便更
好追踪和维护。

body:
body填写详细描述，主要描述改动之前的情况及修改动机
对于小的修改不作要求，但是重大需求、更新等必须添加body来作说明。

break changes:
break changes指明是否产生了破坏性修改，涉及break changes的改动必须指明该项
类似版本升级、接口参数减少、接口删除、迁移等。

affect issues:
affect issues指明是否影响了某个问题。例如我们使用jira时，
我们在commit message中可以填写其影响的JIRA_ID

Git Commit 规范提交