在 Git 提交信息中使用规范化的标识符（也称为类型或前缀）是现代软件开发中一个非常重要的最佳实践。它能让提交历史清晰可读，并且可以方便地自动生成变更日志（CHANGELOG）。
最流行和公认的规范是 Conventional Commits，其基本格式为：
<类型>[可选的作用域]: <描述>
[可选的正文]
[可选的脚注]
基本格式
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
常用且规范的标识符（类型）
下表列出了最核心和常用的提交类型：
| 标识符 (类型) | 说明 | 示例 |
|---|---|---|
feat |
新增功能 (Features) - 当提交引入一个新的功能或特性时使用。这通常对应着语义化版本中的 MINOR 版本更新。 |
feat: 添加用户登录功能 |
fix |
修复缺陷 (Bug fixes) - 当提交修复了一个 bug 时使用。这通常对应着语义化版本中的 PATCH 版本更新。 |
fix: 修复首页图片无法加载的问题 |
docs |
文档更新 (Documentation) - 仅当修改了文档时使用，如 README, CHANGELOG, 代码注释等。 | docs: 更新 API 接口文档 |
style |
代码样式 (Styles) - 指不影响代码含义的更改（空格、格式化、缺少分号等），不是指 CSS 样式。 | style: 按照 ESLint 规范格式化代码 |
refactor |
代码重构 (Refactoring) - 既不是修复 bug 也不是增加新功能的代码更改。即不影响现有功能的内部结构优化。 | refactor: 重构用户模块以提高可读性 |
perf |
性能优化 (Performance) - 提高性能的代码更改。 | perf: 优化列表渲染速度 |
test |
测试相关 (Tests) - 增加缺失的测试或更正现有的测试。 | test: 为用户登录功能添加单元测试 |
build |
构建系统 (Builds) - 影响构建系统或外部依赖的更改（例如：gulp, broccoli, npm, Webpack, Rollup）。 | build: 更新 Webpack 配置至 v5 |
ci |
CI 配置 (Continuous Integrations) - 更改 CI 配置文件和脚本（例如：GitHub Actions, GitLab CI）。 | ci: 在 GitHub Actions 中增加缓存配置 |
chore |
其他改动 (Chores) - 不修改源代码或测试文件的其他更改（更新构建任务、包管理器配置等）。 | chore: 更新 npm 依赖包 |
revert |
回退提交 (Reverts) - 回退之前的某个提交。 | revert: 撤销某次错误的提交 |
进阶用法
作用域 (Optional Scope)
作用域可以用来说明提交的影响范围，通常是代码的一个模块或组件的名称，放在括号内。
示例：
feat(auth): 添加双因素认证fix(router): 修复导航守卫死循环问题refactor(api): 重构用户信息接口
破坏性变更 (Breaking Changes)
当一个提交引入了不向后兼容的 API 变更时，必须在提交信息的正文或脚注中加以说明，并在类型/作用域后添加一个 !，或者正文中包含 BREAKING CHANGE:。
示例：
方式一：在类型后添加 !
feat(api)!: 移除旧版用户查询接口
BREAKING CHANGE: 移除了 `/api/v1/user` 接口，请使用 `/api/v2/member` 替代。
方式二：在正文中说明
chore: 将最低支持的 Node.js 版本提升至 18
BREAKING CHANGE: 项目不再支持 Node.js 16。
完整示例
一个符合规范的提交历史可能看起来像这样：
feat(auth): 新增第三方登录支持
- 添加微信登录功能
- 添加 GitHub 登录功能
Closes #123
---
fix(ui): 修复按钮在移动端的点击区域过小的问题
- 为 .btn 类增加 min-touch-area
Fixes #45
---
docs: 更新项目启动说明
---
chore: 升级 axios 到 ^1.4.0
优势与工具推荐
为什么要这么做？
- 自动化生成 CHANGELOG.md: 工具（如
standard-version）可以根据feat和fix类型自动生成变更日志。 - 自动决定语义化版本: 工具（如
semantic-release）可以根据提交类型自动决定下一个版本号是PATCH,MINOR还是MAJOR。 - 提高可读性: 团队成员和未来的自己可以快速理解每个提交的意图和影响范围。
- 促进代码审查: 清晰的提交信息让 Reviewer 更容易理解你的更改。
工具推荐
为了确保团队成员都遵循这个规范，可以使用以下工具：
- Commitizen: 一个交互式工具，引导你填写符合规范的提交信息。
- commitlint: 一个 Git Hook 工具（通常与 Husky 配合使用），用于在提交时检查提交信息格式是否符合规范。
总结： 最核心、最常用的标识符就是 feat 和 fix，再辅以 docs, style, refactor 等类型，你的提交历史就会变得非常清晰和专业。强烈建议在团队中推广使用。