掌握 Conventional Commits 规范：提升项目版本控制的清晰度与自动化

在软件开发的过程中，版本控制和变更日志的维护是至关重要的。它们不仅帮助开发者追踪项目的演变历程，也为用户和其他开发者提供了清晰的更新说明。为了实现这一目标，Conventional Commits 规范应运而生，旨在提供一种标准化的 Git commit 信息格式，以便自动化工具能够更好地解析和生成变更日志。

什么是 Conventional Commits 规范？

Conventional Commits 是一种约定，它定义了一种特定的 commit 信息格式，使得自动化工具能够理解并据此执行各种任务，如自动生成变更日志、决定版本号的升级策略等。这种规范基于 semver（语义化版本控制）原则，将 commit 信息分为不同的类型，并允许添加可选的脚本来描述更改的性质。

它是一种基于提交消息的轻量级公约，旨在创建清晰、可读的提交历史记录。通过遵循这一规范，我们可以更容易地编写基于规格的自动化工具，例如自动生成版本号和更新日志。

这个规范起源于 Angular 项目的提交准则，并逐渐被许多其他项目和组织所采用。

Conventional Commits 规范的核心要素

Commit 类型

• feat: 新功能（Feature）
• fix: 修复bug（Bugfix）
• docs: 文档变更（Documentation）
• style: 代码格式（不影响代码运行的变动）
• refactor: 代码重构（Refactoring, 无新功能添加，无bug修复）
• perf: 性能优化（Performance Improvement）
• test: 增加测试（Testing）
• chore: 构建过程或辅助工具的变动（如不需要发布新版本的改动）

脚注

• BREAKING CHANGE: 破坏性变更，通常用于 major 版本升级。当 commit 信息中包含这个脚注时，表明此次提交引入了不向后兼容的更改。

如何应用 Conventional Commits 规范

1. 教育团队成员：确保所有团队成员都了解并遵循这种规范。
2. 使用工具辅助：可以使用 commitizen 这样的工具来帮助团队成员生成符合规范的 commit 信息。
3. 在项目中推广：在项目的 README 或其他文档中明确指出使用 Conventional Commits 规范，并提供相应的指南或模板。

自动化工具与 Conventional Commits 规范

使用 Conventional Commits 规范的一个主要好处是能够与各种自动化工具配合使用，如 standard-version、conventional-changelog 等。这些工具可以根据提交的类型和脚注自动生成变更日志，并决定适当的版本号升级策略。

示例

假设你的团队遵循了 Conventional Commits 规范，那么一个典型的 commit 信息可能如下所示：

feat: 添加新的用户认证功能

BREAKING CHANGE: 旧的认证系统已被新的系统替代，请更新你的代码以适应新的 API。
1
2
3

这个 commit 信息表明这是一个新功能的添加（feat），并且包含了一个破坏性变更（BREAKING CHANGE）。

Conventional Commits 规范定义了一系列的 commit 类型，每种类型都有其特定的用途和含义。以下是每种类型的详细说明和使用场景：

1. feat: 新功能（Feature）

使用场景：当你添加了一个新的功能或者改进了现有功能时，应该使用 feat 类型。

示例：

feat: 增加夜间模式切换功能
1

2. fix: 修复bug（Bugfix）

使用场景：当你修复了一个bug或者问题时，应该使用 fix 类型。

示例：

fix: 修复登录页面的输入验证问题
1

3. docs: 文档变更（Documentation）

使用场景：当你更新了项目的文档，比如 README、开发指南或其他文档时，应该使用 docs 类型。

示例：

docs: 更新贡献指南
1

4. style: 代码格式（Style）

使用场景：当你更改了代码的格式，比如缩进、换行、空格等，而这些更改并不影响代码的运行结果时，应该使用 style 类型。

示例：

style: 统一代码缩进为两个空格
1

5. refactor: 代码重构（Refactor）

使用场景：当你重构了代码，即改变了代码的结构或风格，但没有添加新功能或修复bug时，应该使用 refactor 类型。

示例：

refactor: 优化数据库查询逻辑
1

6. perf: 性能优化（Performance Improvement）

使用场景：当你对代码进行了性能提升，比如优化算法、减少内存使用、提高响应速度时，应该使用 perf 类型。

示例：

perf: 优化图片加载速度
1

7. test: 增加测试（Testing）

使用场景：当你添加了新的测试用例或者改进了现有测试时，应该使用 test 类型。

示例：

test: 为用户认证流程添加单元测试
1

8. chore: 构建过程或辅助工具的变动（Chores）

使用场景：当你进行了不涉及代码逻辑的更改，比如构建脚本的更新、依赖管理、配置文件的变动等，应该使用 chore 类型。

示例：

chore: 更新依赖到最新版本
1

9. ci: 持续集成（Continuous Integration）

使用场景：当你更改了与持续集成（CI）流程相关的配置或脚本时，可以使用 ci 类型。

示例：

ci: 修复 GitHub Actions 工作流中的 bug
1

10. revert: 回退（Revert）

使用场景：当你撤销了一个之前的提交时，可以使用 revert 类型，并在消息中指定被撤销的提交信息。

示例：

revert: 撤销 "feat: 添加新的用户认证功能"，因为存在安全隐患
1

11. build: 构建系统（Build）

使用场景：当你更改了项目的构建系统或影响构建过程的文件时，可以使用 build 类型。

示例：

build: 优化 Webpack 配置以减少打包大小
1

12. init: 初始化（Initialization）

使用场景：当你初始化项目或添加了重要的初始化代码时，可以使用 init 类型。

示例：

init: 初始化项目结构和基础配置
1

13.BREAKING CHANGE: 破坏性变更（Breaking Change）

使用场景：当你的提交包含了一个破坏性变更，即这个变更会导致现有功能无法正常工作或API不兼容时，应该在 commit 信息中添加 BREAKING CHANGE 脚注。

示例：

feat: 移除旧的认证方式

BREAKING CHANGE: 旧的认证方式已被移除，请所有用户迁移到新的认证系统。
1
2
3

遵循 Conventional Commits 规范可以帮助你的团队更清晰地记录项目的历史变更，同时也为自动化工具提供了执行任务的基础。确保你的团队成员都了解并遵循这些规范，以便最大化地发挥它们的作用。