让 Git 提交记录体面一点：Conventional Commits 实践

翻一翻祖传仓库的 git log --oneline，总能看到这样的提交：“修复bug”、“一些修改”、“final 最终版”、“update 1111”。三个月后回头排查问题时，这些记录约等于没有。Conventional Commits（约定式提交）就是解这个问题的。

基本格式

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

[可选的正文]
[可选的脚注]

一行看懂的例子：

feat(order): 订单列表支持仅看未读
fix(auth): 修复 token 过期后未跳转登录页的问题
docs: 补充本地开发环境搭建说明

常用 type

feat：新功能（会触发 minor 版本号）；
fix：缺陷修复（会触发 patch 版本号）；
docs / style / refactor / perf / test / chore：文档、格式、重构、性能、测试、杂项，均不改变业务语义；
BREAKING CHANGE：在脚注声明或 subject 后加 !，破坏性变更（触发 major）。

两条容易被忽略的规则

一是 subject 用祈使句、不加句号：写 “add cache” 而不是 “added cache”，保持和 git 官方建议一致，翻阅时整齐得多。二是 一个提交只做一件事：格式化整个文件和修改逻辑分开提交，否则 blame 的时候全是无意义的格式 diff，代码考古直接失明。

用工具兜底

规范靠自觉是不长久的，加一层提交校验即可。commitlint + husky 的最小配置：

// commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'subject-max-length': [2, 'always', 50],
  },
};

# package.json
"husky": {
  "hooks": {
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
}

再配合 conventional-changelog 工具，可以直接从提交历史生成 CHANGELOG。花在写提交信息上的十秒钟，是三个月后的自己最划算的投资。