背景
在软件开发中，版本控制是一个至关重要的环节。Git 是最流行的版本控制系统之一，而 Git 提交信息（commit message）则是记录代码变更的重要方式。而我们经常会遇见：
查看项目 Git 日志时，提交信息杂乱无章，完全看不懂每个提交的意图。
手动编写 CHANGELOG 耗时费力，还容易遗漏重要变更。
团队协作中，成员提交风格不一，代码审查效率低下
为了提高 Git 提交信息的可读性和一致性，Conventional Commits 规范（地址：https://www.conventionalcommits.org/en/v1.0.0/）应运而生。这是一套被 Angular、Vue 等顶级开源项目广泛采用的 Git 提交规范，能将提交信息从混乱的草稿变为清晰的文档。
这里，我们将详细介绍 Conventional Commits 规范的定义、格式、使用场景以及一些最佳实践。
Conventional Commits 规范
Conventional Commits 是一套基于 Git 提交消息的轻量级约定，旨在通过结构化格式提升提交信息的可读性和自动化处理能力。它的核心目标包括：
人类可读：清晰描述提交的意图和影响范围。
机器友好：支持自动化生成 CHANGELOG 和语义化版本（SemVer）。
团队协作：统一提交风格，减少沟通成本。
格式结构
一条规范的提交消息需包含以下部分（部分可选）：
<类型>[可选范围]: <简短描述>
[可选正文]
[可选脚注]1. 类型（type）
类型是提交的核心部分，表示提交的目的和性质。常见的类型包括：
| 类型 | 用途 | 对应 SemVer |
|---|---|---|
| feat | 新增功能 | MINOR（次版本） |
| fix | 修复 Bug | PATCH（补丁版本） |
| BREAKING CHANGE | 破坏性变更（如 API 不兼容） | MAJOR（主版本） |
| docs | 文档更新 | -（不影响版本） |
| style | 代码格式调整（如缩进、空格） | -（不影响版本） |
| refactor | 代码重构（不新增功能或修复 Bug） | -（不影响版本） |
其他推荐类型有：build（构建系统）、ci（持续集成）、test（测试用例）等。
这里我们插一句，对于版本号的控制，可以参考以下规则：
2. 可选范围（scope）
可选范围用于指定提交影响的模块或功能区域。它可以是一个具体的模块名、文件名或其他标识符。范围有助于快速定位问题和理解变更的上下文。
例如：feat(auth): add JWT authentication 表示在 auth 模块中新增了 JWT 身份验证功能。
3. 简短描述（subject）
简短描述是对提交内容的简要说明，通常不超过 72 个字符。它应以小写字母开头，并使用祈使句（imperative mood）来描述变更的目的。
例如：fix: correct typo in README 表示修复了 README 文件中的拼写错误。
4. 可选正文（body）
可选正文用于详细描述提交的内容和背景信息。它可以包含多行文本，通常用于解释为什么要进行此更改、如何实现等。正文应与简短描述之间空一行。
例如：
feat: 支持多语言切换
新增中英文切换按钮，默认跟随系统语言。
依赖第三方库 `i18n-utils`，需运行 `npm install` 安装。 为什么推荐使用
1. 自动化工具支持
生成 CHANGELOG：工具（如 standard-version）可自动从提交历史提取内容生成变更日志。
语义化版本控制：根据提交类型自动升级版本号（feat → MINOR，fix → PATCH，BREAKING CHANGE → MAJOR）。
代码审查加速：通过类型快速定位提交意图，减少沟通成本。
2. 团队协作效率提升
统一提交风格：团队成员遵循相同的提交规范，减少沟通障碍，避免风格混乱。
清晰的历史记录：通过结构化的提交信息，团队成员可以快速了解项目进展和变更。
问题追溯：通过关联的 issue 编号和脚注，快速定位问题和变更历史。
3. 开源项目友好性
开源项目通常需要清晰的文档和变更记录，Conventional Commits 规范可以帮助维护者和用户快速了解项目的演变。
社区贡献者可以通过遵循规范的提交信息，轻松参与项目开发，降低贡献门槛。
Takeaway
Conventional Commits 不仅是技术规范，更是团队协作的沟通协议。通过标准化提交信息，它能将 Git 日志从杂乱的历史记录升级为项目演进的清晰路线图。无论是个人项目还是大型团队，尽早引入这一规范都将显著提升开发效率和代码质量。