git提交格式(Conventional Commits 规范)

Git 提交信息（Commit Message）的标准格式通常遵循 Conventional Commits 规范。这是一种被广泛采用的社区标准（如 Angular、Vue、React 等知名项目都在使用），它能清晰地表达提交意图，并有助于自动生成变更日志（Changelog）和自动化版本号管理。

1. 标准格式结构

一条标准的 Commit Message 由三部分组成：Header （必填）、Body （可选）、Footer（可选）。

text 复制代码

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

详细拆解：

Header（标题行） ：<type>(<scope>): <subject>
- type（必填）：提交的类型，表明这次提交的性质（见下文类型列表）。
- scope （可选）：影响范围，用括号包裹。通常是模块名、文件名或功能区域（如 auth, ui, db, api）。
- subject （必填）：简短的描述。
  - 以动词开头，使用祈使句（如 "add" 而不是 "added" 或 "adds"）。
  - 首字母小写。
  - 结尾不加句号。
  - 长度建议不超过 50 个字符。
Body（正文）：
- 与 Header 之间空一行。
- 详细描述为什么 做这个修改，而不仅仅是做了什么（代码本身已经展示了做了什么）。
- 可以包含多段，每行建议不超过 72 个字符（方便在终端查看）。
Footer（页脚）：
- 与 Body 之间空一行。
- 主要用于两种情况：
  - 破坏性变更 (Breaking Changes) ：以 BREAKING CHANGE: 开头，描述不兼容的修改。
  - 关联问题 ：引用 Issue 或 Bug 编号，如 Closes #123, Fixes #456。

2. Type（提交类型）列表

这是最关键的部分，常用的类型如下：

类型	含义	示例
feat	新增功能 (Feature)	`feat(user): 添加用户登录功能`
fix	修复 Bug (Bug Fix)	`fix(auth): 修复令牌过期导致的登录失败`
docs	文档变更 (Documentation)	`docs: 更新 API 接口文档`
style	格式调整 (Style)	`style: 删除多余空格，格式化代码` (不影响逻辑)
refactor	代码重构 (Refactoring)	`refactor(db): 重构数据库连接池逻辑` (既不是新功能也不是修 Bug)
perf	性能优化 (Performance)	`perf: 优化图片加载速度`
test	测试相关 (Tests)	`test: 增加用户注册流程的单元测试`
chore	构建/工具/杂项 (Chores)	`chore: 升级依赖包版本`, `chore: 修改 .gitignore`
ci	CI/CD 配置	`ci: 修改 GitHub Actions 构建脚本`
revert	回退提交	`revert: 回退 "feat: 添加支付功能"`

3. 示例

✅ 优秀示例

示例 1：简单的新功能

text 复制代码

feat(cart): 添加购物车商品数量增减功能

实现了前端按钮点击事件，后端同步更新数据库库存。
增加了边界检查，防止数量小于 1。

Closes #1024

示例 2：修复 Bug

text 复制代码

fix(api): 修复高并发下订单状态不一致的问题

在分布式锁释放前增加了重试机制，防止因网络波动导致的锁未释放。

Fixes #897

示例 3：破坏性变更 (Breaking Change)

text 复制代码

refactor(auth): 移除旧的 JWT 验证逻辑

BREAKING CHANGE: 移除了 `validateTokenOld` 方法，所有调用方需迁移至 `validateTokenV2`。

4. 为什么要遵守这个规范？

快速理解历史 ：通过 git log --oneline 一眼就能看出哪些是功能开发，哪些是修 Bug。
自动化生成日志 ：工具（如 standard-version, semantic-release）可以自动扫描 commit 历史，生成漂亮的 CHANGELOG.md。
自动版本号管理 ：
- feat -> 触发 Minor 版本升级 (1.1.0 -> 1.2.0)
- fix -> 触发 Patch 版本升级 (1.1.0 -> 1.1.1)
- BREAKING CHANGE -> 触发 Major 版本升级 (1.1.0 -> 2.0.0)
代码审查 (Code Review)：审查者能更快理解提交意图。

5. 辅助工具推荐

如果你手动写觉得麻烦或容易忘，可以使用以下工具强制规范：

Commitizen : 一个命令行工具，通过交互式问答引导你生成标准的 commit message。
bash 复制代码
```
npx commitizen
```
Husky + Commitlint : 在 Git Hook 中拦截不符合规范的提交，强制要求团队遵守标准。
- 安装后，如果你写了 git commit -m "fix bug"，它会报错并拒绝提交，提示你格式错误。

总结速查

记住这个口诀：

类型(范围): 动词开头短句
空一行
详细描述为什么
空一行
关联 Issue 或破坏性说明

例如：
feat(auth): add google login support