规范Git代码提交
git本身自带hooks入口,用户可以在客户端通过脚本的方式在git命令执行前后进行一些检查工作,使用的脚本语言为Shell。
启用本地commit-msg检查
相关hook脚本放在本地.git/hooks目录下,打开该目录可以看到很多示例脚本。
这里使用的是commit-msg,只需要将对应脚本的后缀.sample去掉并修改为自己的脚本逻辑即可启用。
commit-msg
在 commit-msg hooks 中,我们需要对 commit 消息和用户进行校验。
#!/bin/sh
# head: <type>(<scope>): <subject>
# - type: feat, fix/to, docs, style, refactor, test, chore,build,revert, perf,ci,release,workflow
# - scope: can be empty (eg. if the change is a global or difficult to assign to a single component)
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# footer:
# - Include a link to the ticket, if any.
# - BREAKING CHANGE
#
# 用 `` 可以将命令的输出结果赋值给变量
# 获取当前提交的 commit msg
COMMIT_MSG=`cat $1 | egrep "^(feat|fix|to|docs|style|refactor|perf|test|build|chore|release|merge|sync|ci|workflow)(\(.+\))?:\s\w.*"`
test "" != "$COMMIT_MSG" || {
echo "不合法的 commit 消息提交格式,请使用正确的格式:"
echo -e "<type/类型必填>[<scope/作用域可选>]: <subject/描述必填> \
\n<BLANK LINE> \
\n<body/正文可选> \
\n<BLANK LINE> \
\n<footer/正文可选>"
echo -e "有效type类型:\
\nfeat: 新功能 \
\nfix/to: 修复bug\
\n fix: 产生diff并自动修复此问题。适合于一次提交直接修复问题\
\n to: 只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix\
\ndocs: 文档注释(documentation),只改动了文档相关内容\
\nstyle: 格式,不影响代码含义的改动,例如去掉空格、改变缩进、增删分号\
\nrefactor: 代码重构,即不是新增功能,也不是修改bug的代码变动 \
\nbuild: 构造工具的或者外部依赖的改动\
\nrevert: 回滚到上一个版本\
\nperf: 优化相关,比如提升性能、体验\
\ntest: 增加或修改测试\
\release: 发布\
\nci: 与CI(持续集成服务)有关的改动\
\nchore: 不修改src或者test的其余修改构建过程或辅助工具的变动\
\nmerge: 代码合并\
\nsync: 同步主线或分支的Bug"
# 异常退出
exit 1
}
# message 长度校验
if [ ${#COMMIT_MSG} -lt 15 ]; then
echo "Commit Message 内容太短了,请再详细点!\n"
exit 1
fi
# 获取用户 email
email=`git config user.email`
email_re="@abc\.com"
if [[ ! $email =~ $email_re ]]
then
echo "此用户没有权限,具有权限的用户为: xxx@abc.com"
# 异常退出
exit 1
fi
在 commit-msg 钩子触发时,对应的脚本会接收到一个参数,这个参数就是 commit 消息,通过 cat $1 获取commit消息并用egrep判断是否符合规范,结果赋值给 commit_msg 变量。
对提交信息长度进行验证,需要长度大于15个字符
对用户权限做判断则比较简单,只需要检查用户的邮箱或用户名就可以。