提交规范格式要求：让代码协作更高效

为什么需要提交规范格式要求

在团队开发中，每天都有人提交代码。如果每个人写提交信息都随心所欲，比如“改了点东西”、“修复bug”、“再试试”，时间一长，翻记录就像拆盲盒——根本不知道哪次改动对应哪个功能或问题。

我之前参与一个项目，历史提交记录里满是“update”、“fix bug”这种信息。后来线上出了个问题，想用 git bisect 查是哪次引入的，结果点开每个提交都看不出干了啥，最后只能靠翻代码对比，白白浪费半天。

常见的提交信息结构

一个清晰的提交信息不是随便打几个字就行，它有约定俗成的格式。目前最流行的是 Conventional Commits 规范，结构如下：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

其中 type 是必填的，表示这次提交的性质。常用的有：

• feat：新增功能
• fix：修复缺陷
• docs：文档修改
• style：格式调整（不影响逻辑）
• refactor：重构代码
• test：增加测试
• chore：构建过程或辅助工具变动

实际例子

比如你加了个登录按钮，可以这样写：

feat(auth): add login button to homepage

如果修复了一个表单验证的问题：

fix(form): validate email format on submit

当改动比较复杂，需要补充说明时，可以加上 body：

refactor(api): migrate user service to RESTful endpoints

- replace old RPC calls with Axios
- update response handling logic
- remove deprecated URL constants

工具帮你守住规范

靠人自觉很难持久，最好用工具卡住提交流程。比如用 commitlint 检查格式，搭配 husky 在 git commit 时自动触发。

安装后配个 .commitlintrc.json：

{
  "rules": {
    "type-empty": [2, "never"],
    "type-enum": [
      2,
      "always",
      [
        "feat",
        "fix",
        "docs",
        "style",
        "refactor",
        "test",
        "chore"
      ]
    ]
  }
}

再配上 husky 的 hook，一旦提交信息不合规则，直接拒绝提交，逼你写清楚。

对团队的真实好处

一开始大家可能觉得麻烦，但用熟了反而省事。生成 changelog 可以一键完成，CI/CD 系统能根据提交类型判断是否发版，甚至自动化语义化版本号升级。

更重要的是，新成员看历史记录能快速理解项目脉络。谁也不希望接手一个“谜语人”留下的仓库吧？