git 提交信息的规范

前言

想了解Git提交信息的规范，这是团队协作中保证代码可维护性、追溯性的核心规则——规范的提交信息能让所有人快速理解每次提交的目的，也便于自动化生成版本日志、定位问题。以下是行业通用的Git提交信息规范（以最主流的Conventional Commits为例），兼顾实用性和易落地性：

一、核心规范（Conventional Commits 1.0.0）

提交信息的标准结构（一行式，复杂场景可加正文/脚注）：

<类型>[可选作用域]: <描述>

[可选正文]

[可选脚注]

1. 必选部分：类型 + 描述

字段	说明
类型	提交的核心目的，必须小写，常用值如下：
	- feat: 新增功能（feature）
	- fix: 修复bug（fix）
	- docs: 仅修改文档（如README、注释）
	- style: 代码格式修改（不影响逻辑，如空格、缩进、命名）
	- refactor: 重构（既不是新增功能，也不是修复bug）
	- test: 新增/修改测试用例
	- chore: 构建/工具链相关修改（如依赖、配置文件、脚本）
	- perf: 性能优化
	- revert: 回滚之前的提交
可选作用域	提交影响的模块/文件，括号包裹，如feat(login):、fix(course-record):
描述	简短描述（≤50字符），首字母小写，结尾不加标点，用祈使句（如“新增用户登录接口”而非“新增了用户登录接口”）

2. 可选部分：正文 + 脚注

• 正文：详细说明提交的原因、修改内容，换行后编写，每行≤72字符；
• 脚注：用于标注特殊信息，如：
  • 修复的bug编号：Fixes #123（关联Issue 123）；
  • 不兼容变更：BREAKING CHANGE: 接口参数xxx改为yyy；
  • 回滚说明：Reverts commit abc123。

二、示例（从简单到复杂）

1. 简单场景（一行式）

feat(login): 新增验证码登录接口
fix(course-record): 修复查询时user_id列名错误
docs(readme): 补充接口调用示例
style(controller): 调整代码缩进格式
chore(deps): 升级mybatis-plus到3.5.15

2. 复杂场景（带正文+脚注）

fix(order): 修复订单支付后状态未更新问题

- 新增支付回调的事务处理，确保状态更新原子性
- 补充支付失败的日志打印，便于排查问题

Fixes #456
BREAKING CHANGE: 支付回调接口的参数`status`改为`pay_status`

3. 回滚提交

revert: feat(login): 新增验证码登录接口

This reverts commit abc1234567890.

原因：验证码逻辑存在安全漏洞，暂回滚待修复

三、落地建议（新手易执行）

1. 基础规则（必须遵守）

• 提交信息语言：团队统一用中文/英文（建议中文，避免翻译歧义）；
• 描述简洁：核心信息一眼能看明白，不写废话（如“修改了代码”→ 改为“fix: 修复查询接口404问题”）；
• 单次提交单一职责：一个提交只做一件事（如“新增功能+修复bug”拆分为两个提交）。

2. 工具辅助（降低成本）

• 提交前校验：用commitlint+husky强制校验提交信息格式（前端/后端项目都可配置）；

  # 安装依赖
  npm install --save-dev @commitlint/cli @commitlint/config-conventional husky
  # 配置commitlint规则
  echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
  # 启用husky钩子
  npx husky install
  npx husky add .husky/commit-msg 'npx --no -- commitlint --edit $1'

• 可视化工具：用SourceTree、GitKraken等GUI工具，提交时按模板填写，避免手动拼写错误。

3. 团队约定（灵活调整）

• 作用域可按项目模块定义（如你的项目：course-record、user、config）；
• 类型可精简（新手先掌握feat/fix/docs/chore即可）；
• 禁止无意义提交（如“更新代码”“测试一下”“fix bug”）。

四、反例（需要避免）

# ❌ 无类型，描述模糊
更新代码

# ❌ 类型错误（修复bug用了feat）
feat: 修复查询接口404问题

# ❌ 描述冗长且不清晰
fix: 改了course_record的sql，之前的user_id不对，现在换成userid了，还调整了参数

# ❌ 多个修改混在一起
feat: 新增登录接口+修复订单bug+更新文档

总结

1. Git提交信息的核心是「清晰、可追溯」，主流规范为Conventional Commits，结构是类型[作用域]: 描述；
2. 新手先掌握核心类型（feat/fix/docs/chore）+ 简短描述，再逐步补充正文/脚注；
3. 团队协作时建议用工具（commitlint+husky）强制校验，避免不规范提交。

遵循这个规范，你和团队能快速定位每次提交的目的，后续查日志、回滚、生成版本说明都会事半功倍。