Commit规范实践指南：提升团队协作效率的关键技巧

为什么我又要折腾 Commit 规范？

说实话，我一开始对 Commit 规范是无感的。自己写代码，自己看，随便写个“fix bug”不也挺好？但自从项目上了 CI/CD、开始自动生成 CHANGELOG、还要配合语义化发布（semantic release）之后，我就栽了几个大坑。比如某次因为 commit message 写成“修复了个问题”，导致 release 脚本没识别出这是个 fix，结果跳过了 patch 版本，线上用户直接炸了。

从那以后，我开始认真对待 Commit 规范。市面上主流方案其实就那么几个：Conventional Commits（配合 commitlint + husky）、Commitizen + cz-conventional-changelog、还有手写脚本 + git hooks。今天我就说说我踩过的坑，以及我最终选了哪个——不是最完美的，但最适合我。

谁更灵活？谁更省事？

先说结论：我比较喜欢用 Conventional Commits + commitlint + husky 这套组合拳。虽然配置有点啰嗦，但胜在标准化、社区支持好、和工具链无缝集成。下面我一个个拆开讲。

手写脚本 + git hooks：自由但容易翻车

最原始的方式，就是自己写个 pre-commit 或 commit-msg 的 hook，用 shell 或 Node.js 校验 message 格式。比如：

#!/bin/sh
# .git/hooks/commit-msg
msg=$(head -n1 "$1")
if ! echo "$msg" | grep -qE '^(feat|fix|docs|style|refactor|test|chore)((.+))?: .+'; then
  echo "Commit message format error!"
  echo "Example: feat(auth): add login button"
  exit 1
fi

看起来挺简单，对吧？但问题来了：团队里有人用 Windows，有人用 Mac，hook 文件权限老出问题；新人根本不知道要手动复制 hook 到 .git/hooks；改个规则就得所有人同步更新脚本。我折腾过两次，最后都放弃了——自由度太高，反而成了维护负担。

Commitizen：交互式提交，但有点“重”

Commitizen 的思路很聪明：你不用记格式，它用交互式命令行一步步问你 type、scope、description。装完后执行 git cz 就行。

npm install -g commitizen
commitizen init cz-conventional-changelog --save-dev --save-exact

然后你运行：

git cz

它会弹出一堆选项让你选。对新手确实友好，但问题也很明显：

• 每次提交都要敲 git cz，不能直接 git commit，流程变长
• 如果你习惯用 VS Code 的 Git 图形界面，它不认 git cz，得切回终端
• 配置稍微复杂，尤其在 monorepo 里，每个 package 都要配一遍

我试过在小项目里用，体验还行。但一到大项目，大家嫌麻烦，又偷偷写 “update file” 回去了。所以现在我基本不推这个方案了——除非团队全是新人，且愿意接受强制流程。

Conventional Commits + commitlint + husky：我的主力方案

这套是目前最主流的，也是我最终选定的。核心思想是：用 commitlint 校验 commit message 是否符合 Conventional Commits 规范，用 husky 在 commit 时自动触发校验。

安装起来也不难：

npm install --save-dev @commitlint/cli @commitlint/config-conventional husky
npx husky install
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit $1'

然后在 package.json 里加个配置：

{
  "commitlint": {
    "extends": ["@commitlint/config-conventional"]
  }
}

这样，只要你执行 git commit，就会自动检查 message。比如你写：

git commit -m "fix login issue"

它会报错，因为缺少 scope（虽然 scope 是可选的，但 description 前必须有冒号）。正确写法是：

git commit -m "fix(auth): resolve token expiration bug"

这里注意我踩过好几次坑：husky 的版本很重要！ v7 之后初始化方式变了，很多人照着旧教程配，结果 hook 不生效。另外，如果你用的是 pnpm，记得加 --no-install 避免重复安装。

这套方案的优点很明显：

• 和标准工具链（如 semantic-release、standard-version）天然兼容
• 校验逻辑集中，改规则只需改 commitlint config
• 不影响原有 git 流程，开发者还是用熟悉的 git commit

缺点也有：初期配置略繁琐，但一旦配好，几乎不用动。而且现在像 Vite、Next.js 的官方模板都默认集成了，说明社区已经认可了。

我的选型逻辑

我选技术方案从来不追求“最先进”，只看三点：能不能自动化、会不会增加团队负担、出问题好不好修。

手写脚本？自动化程度低，排除。
Commitizen？交互虽好，但打断现有工作流，排除。
Conventional Commits + commitlint + husky？虽然要配几行代码，但一劳永逸，CI 也能复用同一套规则（比如在 PR 检查里跑 commitlint），团队适应成本低。

所以，我现在所有新项目都默认上这套。哪怕是个小 demo，我也配一下——因为谁知道哪天它就变成正式项目了呢？

一点不完美的细节

当然，这套也不是 100% 完美。比如 merge commit 或 revert commit 会被 commitlint 拦住，这时候得加 --no-verify 绕过。还有，有些老同事真的记不住格式，总写成 “feat: add xxx” 漏了 scope，虽然规范允许 scope 可选，但团队最好统一风格。

不过这些小问题，比起收益来说，完全可以接受。毕竟，能自动生成 CHANGELOG 和自动发版，省下的时间远比调教 commit message 多得多。

以上是我个人对 Commit 规范方案的完整对比和实战总结，有更优的实现方式欢迎评论区交流。这个技巧的拓展用法还有很多（比如结合 Lerna 做 monorepo 发布），后续会继续分享这类博客。