团队git提交规范--husky

为什么要统一git提交风格

日常工作中，几乎每个项目都是由多个人进行维护，每个人的代码书写习惯和风格又不尽相同，在这种情况下，如果没有统一的规范，你就会发现提交到代码仓库的代码格式五花八门，并且commit log也是乱七八糟

什么是Husky

You can use it to lint your commit messages, run tests, lint code, etc... when you commit or push. Husky supports all Git hooks.

这是来自官网的介绍，由最后一句可以看出 Husky 其实是一个 Git Hooks 工具。

什么是Git Hooks

类似于前端框架中的生命周期钩子，git在某些特定事件发生前或后也会有某些执行特定功能的钩子，githooks就是在git执行特定事件（如commit、push、receive等）时触发运行的脚本。

githooks 保存在 .git 文件夹中

具体钩子如下表所示：

git hook	执行时机	说明
applypatch-msg	git am 执行前	默认情况下，如果commit-msg启用的话，applpatch-msg钩子在启用时会运行commit-msg钩子
pre-applypatc	git am 执行前	默认的pre-applypatch钩子在启用时运行pre-commit钩子（如果后者已启用）
post-applypatch	git am 执行后	这个钩子主要用于通知，不能影响git-am的结果
pre-commit	git commit 执行前	可以使用 git commit --no verify 命令绕过该钩子
pre-merge-commit	git merge 执行前	可以使用 git merge --no verify 命令绕过该钩子
prepare-commit-msg	git commit执行之后，编辑器打开之前
commit-msg	git commit 执行前	可以使用 git commit --no verify 命令绕过该钩子
post-commit	git commit 执行后	不影响git commit的结果
pre-rebase	git rebase执行前
post-checkout	git checkout 或 git switch执行后	如果不使用 --no-checkout 参数，则在 git clone 之后也会执行
post-merge	git merge 执行后	在执行git pull 时也会被调用
pre-push		git push 执行前
pre-receive	git receive pack 执行前
update
proc-receive
post-receive	git receive pack 执行前	不影响 git receive pack 的执行结果
post-update	当git receive pack对 git push 作出反应并更新仓库中的引用时
reference-transaction
push-to-checkout	当git receive pack对 git push 作出反应并更新仓库中的引用时，以及当推送试图更新当前被签出的分支且 receive.denyCurrentBranch配置被updateInstead时
pre-auto-gc	git gc --auto 执行前
post-rewrite	执行 git commit --amend 或 git rebase 时
sendemail-validate	git send-email 执行前
fsmonitor-watchman	配置core.fsmonitor被设置为.git/hooks/fsmonitor-watchman 或.git/hooks/fsmonitor-watchmanv2时
p4-changelist	git-p4 submit 执行并编辑完changelist message 之后	可以使用 git-p4 submit --no-verify绕过该钩子
p4-prepare-changelist	git-p4 submit 执行后，编辑器启动前	可以使用 git-p4 submit --no-verify绕过该钩子
p4-post-changelist	git-p4 submit 执行后
p4-pre-submit	git-p4 submit 执行前	可以使用 git-p4 submit --no-verify绕过该钩子
post-index-change	索引被写入 read-cache.c do_write_locked_index后

代码提交规范

类型	描述
feat	新增feature
fix	修复bug
docs	仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等;
style	仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑;
refactor	代码重构，没有加新功能或者修复bug
perf	优化相关，比如提升性能、体验
test	测试用例，包括单元测试、集成测试等
chore	改变构建流程、或者增加依赖库、工具等
revert	回滚到上一个版本

husky 使用

安装

npm install -D husky

初始化

npx husky install

本文仅讲如何在git commit的时候检查 commit名是否符合规范

1. 在根目录下创建 scripts/verifyCommit.js

verifyCommit.js

// eslint-disable-next-line no-undef
const msg = require('fs')
  .readFileSync('.git/COMMIT_EDITMSG', 'utf-8')
  .trim()
  
  // feat: 新功能
  // fix: 修改 bug
  // docs: 文档
  // perf: 性能相关
  // refactor: 代码重构（就是不影响使用，内部结构的调整）
  // test: 测试用例
  // style: 样式修改
  // workflow: 工作流
  // build: 项目打包构建相关的配置修改
  // ci: 持续集成相关
  // revert: 恢复上一次提交（回滚）
  // wip: work in progress 工作中 还没完成
  // chore: 其他修改（不在上述类型中的修改）
  // release: 发版
  // deps: 依赖相关的修改

const commitRE = /^(revert: )?(feat|fix|docs|dx|style|refactor|perf|test|workflow|build|ci|chore|types|wip|release)(\(.+\))?: .{1,50}/
const mergeRe = /^(Merge pull request|Merge branch)/
console.log('msg', msg)
if (!commitRE.test(msg)) {
  if(!mergeRe.test(msg)){
    console.log('git commit信息校验不通过')

    console.error(`git commit的信息格式不对, 需要使用 title(scope): desc的格式
      比如 fix: xxbug
      feat(test): add new 
      具体校验逻辑看 scripts/verifyCommit.js
    `)
    // eslint-disable-next-line no-undef
    process.exit(1)
  }

}else{
  console.log('git commit信息校验通过')
}

2. 新增commit-msg钩子, 在 git commit 执行前，先运行 verifyCommit.js，判断git commit是否符合规则

npx husky add .husky/commit-msg "node scripts/verifyCommit.js"

这命令会在.husky文件下生成一个commit-msg文件

之后每次git commit 执行的时候都会自动判断名称是否符合规范

3. 也可以在 commit 执行前先运行下 eslint，检查下代码符不符合规范

npx husky add .husky/pre-commit "npm run lint"