在协作软件开发团队中，提交消息结构的不一致会使跟踪更改变得困难。诸如 fix bug、update code 或 minor changes 之类的模糊提交消息会使代码审核和延迟发布文档变得复杂。
为了解决此问题并维护干净、机器可读的提交历史记录，世界各地的开发人员采用常规提交规范。
在本文中，我们将解释常规提交的结构、标准前缀分类以及该规则如何实现自动化发布操作。
1. 常规提交的结构
常规提交为提交日志建立了标准化布局。核心模板结构如下：
<type>(<scope>): <description>
[optional body]
[optional footer(s)]
- 类型：更改的意图（必填）
- 范围：受影响的模块或子系统（可选，例如
auth、payment） - 描述：变更的简明摘要（必填）
- 正文：深入的解释或理由（可选）
- 页脚：重大更改或参考 ID（可选，例如
Refs #104）
实际例子：
feat(auth): increase minimum password length requirement to 8 characters
To align with modern security policies, all login registrations and credential updates
now validate that passwords are at least 8 characters long.
Closes #142
2. 标准类型及含义
选择正确的类型前缀是保持历史有意义的关键。以下是标准类型：
| 类型 | 定义 |
|---|---|
| 壮举 | 向代码库引入了一项新功能。 |
| 修复 | 修补应用程序中的错误。 |
| 文档 | 对文档的修改（例如自述文件或内联注释）。 |
| 风格 | 非功能性更改（格式、分号、空格调整）。 |
| 重构 | 代码重组既不修复错误也不添加功能。 |
| 性能 | 性能优化修订。 |
| 测试 | 添加缺少的测试或修复现有测试。 |
| 家务 | 日常任务（依赖项、构建配置、npm 包）。 |
| ci | CI 管道调整（例如 GitHub Actions 工作流程文件）。 |
3. 实施常规提交的好处
① 可读可搜索的历史记录
标准化前缀使提交日志易于扫描。您可以立即筛选提交以仅查看给定时间范围内添加的错误 (fix) 或功能 (feat)。
② 自动生成 CHANGELOG
由于提交是结构化的，因此 standard-version 或 release-it 等工具可以解析您的 git 历史记录，并在发布周期中自动输出格式化的 CHANGELOG.md 文件。
③ 语义版本控制（SemVer）自动化
高级发布系统（如 semantic-release）读取常规提交以自动计算版本增量：
fix触发 Patch 版本提升（例如1.0.0->1.0.1）。feat触发 次要 版本提升（例如1.0.0->1.1.0）。BREAKING CHANGE页脚会触发 主要 版本变更（例如1.0.0->2.0.0）。
结论
适应传统提交可能需要进行简短的调整，但在清晰度、文档质量和管道自动化方面的回报是巨大的。开始将这些前缀集成到您的开发工作流程中，以构建更清晰的项目历史记录。