Skip to main content

Committer 规范

目标

规范开发者每次提交本地代码到远程仓库

提交信息结构

统一格式：

<type>(scope?): <short summary>

[optional body]

[optional footer(s)]
  • type：本次提交的类型（必填）
  • scope：影响范围（可选，比如模块名、包名）
  • short summary：一句话说明做了什么（必填）
  • body：必要时补充动机、实现思路（可选，多行）
  • footer：放关联 issue、BREAKING CHANGE 等（可选）

示例：

feat(api): add user login endpoint

Support JWT-based login and return user profile in response.

Closes #123

类型（type）约定

常用 6 个就够用：

  • feat：新增功能（feature）
  • fix：修复 bug
  • docs：文档调整（仅文档）
  • style：格式变动（不影响逻辑，如空格、格式化）
  • refactor：代码重构（不加新功能、不修 bug）
  • test：测试相关（新增/修改测试）
  • chore：杂项（构建、依赖、脚本、CI 配置等）
feat: add user profile page
fix: handle null user in login
docs: update installation guide
style: format code with prettier
refactor: extract auth middleware
test: add tests for user service
chore: bump typescript to 5.0

简短说明（summary）规则

  • 使用中文或英文统一（团队自己定一个）
  • 不超过 72 个字符为宜
  • 用「做了什么」，不要写「修复 bug」这类没信息量的内容
  • 用祈使语气（英文时建议用动词原形开头，例如：add/update/fix）

对比：

  • 不推荐：fix: bug
  • 更好：fix: avoid crash when user has no email

提交粒度（怎么拆提交）

  • 一个提交尽量只做一件事：
    • 「修改 UI + 重构接口 + 调整依赖」请拆成多个 commit
  • 避免超大提交（超过几百行改动时，通常说明可以拆）
  • 机械性格式化/重排代码的提交单独一个：
    • style: format project with prettier

关联 Issue 和重要变更

  • 关联 issue：
fix: handle null user in login

Closes #123
  • 引入不兼容变更（Breaking Change）时，必须说明：
feat: remove legacy auth api

BREAKING CHANGE: /v1/auth/login has been removed, use /v2/auth/login instead.

Back to top