在软件开发的过程中，版本控制和变更日志的维护是至关重要的。它们不仅帮助开发者追踪项目的演变历程，也为用户和其他开发者提供了清晰的更新说明。为了实现这一目标，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 规范
- 教育团队成员：确保所有团队成员都了解并遵循这种规范。
- 使用工具辅助：可以使用
commitizen这样的工具来帮助团队成员生成符合规范的 commit 信息。 - 在项目中推广：在项目的 README 或其他文档中明确指出使用
Conventional Commits规范，并提供相应的指南或模板。
自动化工具与 Conventional Commits 规范
使用 Conventional Commits 规范的一个主要好处是能够与各种自动化工具配合使用，如 standard-version、conventional-changelog 等。这些工具可以根据提交的类型和脚注自动生成变更日志，并决定适当的版本号升级策略。
示例
假设你的团队遵循了 Conventional Commits 规范，那么一个典型的 commit 信息可能如下所示：
feat: 添加新的用户认证功能BREAKING CHANGE: 旧的认证系统已被新的系统替代，请更新你的代码以适应新的 API。
这个 commit 信息表明这是一个新功能的添加（feat），并且包含了一个破坏性变更（BREAKING CHANGE）。
Conventional Commits 规范定义了一系列的 commit 类型，每种类型都有其特定的用途和含义。以下是每种类型的详细说明和使用场景：
1. feat: 新功能（Feature）
使用场景：当你添加了一个新的功能或者改进了现有功能时，应该使用 feat 类型。
示例：
feat: 增加夜间模式切换功能
2. fix: 修复bug（Bugfix）
使用场景：当你修复了一个bug或者问题时，应该使用 fix 类型。
示例：
fix: 修复登录页面的输入验证问题
3. docs: 文档变更（Documentation）
使用场景：当你更新了项目的文档，比如 README、开发指南或其他文档时，应该使用 docs 类型。
示例：
docs: 更新贡献指南
4. style: 代码格式（Style）
使用场景：当你更改了代码的格式，比如缩进、换行、空格等，而这些更改并不影响代码的运行结果时，应该使用 style 类型。
示例：
style: 统一代码缩进为两个空格
5. refactor: 代码重构（Refactor）
使用场景：当你重构了代码，即改变了代码的结构或风格，但没有添加新功能或修复bug时，应该使用 refactor 类型。
示例：
refactor: 优化数据库查询逻辑
6. perf: 性能优化（Performance Improvement）
使用场景：当你对代码进行了性能提升，比如优化算法、减少内存使用、提高响应速度时，应该使用 perf 类型。
示例：
perf: 优化图片加载速度
7. test: 增加测试（Testing）
使用场景：当你添加了新的测试用例或者改进了现有测试时，应该使用 test 类型。
示例：
test: 为用户认证流程添加单元测试
8. chore: 构建过程或辅助工具的变动（Chores）
使用场景：当你进行了不涉及代码逻辑的更改，比如构建脚本的更新、依赖管理、配置文件的变动等，应该使用 chore 类型。
示例：
chore: 更新依赖到最新版本
9. ci: 持续集成（Continuous Integration）
使用场景：当你更改了与持续集成（CI）流程相关的配置或脚本时，可以使用 ci 类型。
示例：
ci: 修复 GitHub Actions 工作流中的 bug
10. revert: 回退（Revert）
使用场景：当你撤销了一个之前的提交时，可以使用 revert 类型，并在消息中指定被撤销的提交信息。
示例：
revert: 撤销 "feat: 添加新的用户认证功能"，因为存在安全隐患
11. build: 构建系统（Build）
使用场景：当你更改了项目的构建系统或影响构建过程的文件时，可以使用 build 类型。
示例：
build: 优化 Webpack 配置以减少打包大小
12. init: 初始化（Initialization）
使用场景：当你初始化项目或添加了重要的初始化代码时，可以使用 init 类型。
示例：
init: 初始化项目结构和基础配置
13.BREAKING CHANGE: 破坏性变更（Breaking Change）
使用场景：当你的提交包含了一个破坏性变更，即这个变更会导致现有功能无法正常工作或API不兼容时，应该在 commit 信息中添加 BREAKING CHANGE 脚注。
示例：
feat: 移除旧的认证方式BREAKING CHANGE: 旧的认证方式已被移除，请所有用户迁移到新的认证系统。
遵循 Conventional Commits 规范可以帮助你的团队更清晰地记录项目的历史变更，同时也为自动化工具提供了执行任务的基础。确保你的团队成员都了解并遵循这些规范，以便最大化地发挥它们的作用。
)
