右耳听风
0%

规范团队 Git Commit Message

发表于

起因

目前正在推动团队做持续部署，包括自动提交 npm 包到公司私库和自动生成 CHANGELOG，重中之重是根据 commit 来自动判断版本号，所以规范 git commit message 势在必行。
本文就介绍下团队是如何做的 commit message 的规范和格式化。

Commit Message 格式

1
<type>(<scope>): <subject>

type(必须)

  • feat: 新功能（feature）
  • fix: 修复 bug
  • perf: 优化相关，比如提升性能、体验
  • refactor: 重构（即不是新增功能，也不是修改 bug 的代码变动）
  • docs: 文档（documentation）
  • style: 格式（不影响代码运行的变动, 不是 css 样式）
  • test: 增加测试

scope(可选)

  • scope 用于说明 commit 影响的范围

subject(必须)

  • subject 是 commit 目的的简短描述，不超过 50 个字符。
1
2
3
e.g.
fix: 修复xxx问题
feat: 新增xxx功能

Commintlint 校验你的 Message

commitlint 可以帮助我们 lint commit messages, 如果我们提交的不符合预设的规范, 直接拒绝提交。

目前团队使用的是
@commitlint/config-conventional，因为团队后面要使用
@semantic-release/commit-analyzer进行一系列自动化操作，

，二者底层均依赖conventional-changelog-conventionalcommits，属于完美适配。

结合 Husky

本地校验 commit message 的最佳方式是结合 git hook, 所以需要配合 Husky。

1
2
3
4
5
npm install husky --save-dev

npx husky install

npm set-script prepare "husky install"
执行完上面命令将带来以下几个变化
  • 在.git 同级目录生成.husky 文件夹，文件夹下有一个可以编辑的示例 pre-commit 钩子
  • 在 package.json 中的 scripts 中添加了”prepare”: “husky install”
  • 更改 git 配置项 core.hooksPath 为.husky
package.json 配置:
1
2
3
4
5
"husky": {
        "hooks": {
            "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
        }
    },

shell 脚本

上文的操作中会有一个小 bug，就是在本地绕过 git hook 校验的情况，当通过 gitlab 做持续部署时，会导致自动计算版本号等操作出错，所以在持续部署脚本启动前，通过 commit lint shell 脚本来避免这种情况发生。

最后

commit message 的规范性很重要, 但是是否需要像本文这样强制限制, 每个团队和个人都有自己的想法, 但是个人认为: 好的习惯, 受益终身.