Git 提交规范与 Conventional Commits 实践

为什么需要提交规范#

团队提交历史常常变成一团乱麻：fix bug、update、改了一下。这类信息对半年后的你毫无价值。好的提交信息应当回答两个问题：

1. 改了什么（what）
2. 为什么改（why）

提交规范的价值在于：机器可解析、人类可读、能自动生成 CHANGELOG、能推导语义化版本号。

Conventional Commits 规范#

格式如下：

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

3
<body>
4

5
<footer>

• type：提交类型（见下表）
• scope：可选，影响范围（模块/组件）
• subject：简短描述，祈使句、不加句号、不超过 50 字
• body / footer：可选，说明动机与破坏性变更

1
feat(auth): 支持 OAuth2 第三方登录
2

3
新增 Google / GitHub 登录入口，用户信息通过 JWT 下发。
4

5
BREAKING CHANGE: 旧的 session 鉴权接口已下线。

用 commitlint + husky 自动校验#

光靠自觉不够，用工具在提交前拦下来。先在项目里加 commitlint.config.js：

1
module.exports = {
2
  extends: ['@commitlint/config-conventional'],
3
}

再用 husky 挂一个 commit-msg 钩子：

1
npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"

此后不符合规范的提交会被直接拒绝，并提示正确格式。

从提交推导版本号#

有了结构化提交，可以用 standard-version 或 semantic-release 自动：

• fix → 升 patch（1.0.0 → 1.0.1）
• feat → 升 minor（1.0.0 → 1.1.0）
• BREAKING CHANGE → 升 major（1.0.0 → 2.0.0）

同时自动生成 CHANGELOG，无需手工维护。

规范不是束缚，而是给未来的自己和协作者留的一份地图。