Git Commit 约定式提交规范：构建清晰、可追溯的提交历史

在团队协作和开源项目中，清晰、标准化的 Git 提交信息（Commit Message）至关重要。它不仅能帮助开发者快速理解代码变更，还能实现自动化生成 Changelog、自动触发版本发布等功能。目前业界最广泛认可的标准是 约定式提交规范 (Conventional Commits)。

1. 提交信息的基本格式

约定式提交的消息结构如下：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

2. 常见提交类型详解

2.1 核心类型 (Core Types)

核心类型直接反映了代码库的主要变动：

• feat (feature): 引入一个新功能。
  示例: feat(auth): 添加短信验证码登录功能
• fix: 修复了一个 Bug。
  示例: fix(api): 修复用户列表分页失效的问题
• docs: 仅修改了文档（如 README, API 文档, 注释等）。
• style: 不影响代码含义的修改。指格式化、缺失分号、空格等，注意：不是指修改 CSS 样式。
• refactor: 代码重构。既不修复 Bug 也不添加新功能的代码更改。

2.2 辅助类型 (Auxiliary Types)

辅助类型用于描述构建流程、性能优化等非业务逻辑的改动：

• perf (performance): 提高性能的代码更改。
• test: 添加缺失的测试或修正现有的测试。
• chore: 日常事务。对构建过程或辅助工具和库（如文档生成）的更改，且不修改源文件。
• build: 影响构建系统或外部依赖项的更改（如 gulp, npm, webpack, maven 依赖）。
• ci: 修改 CI 配置文件和脚本（如 GitHub Actions, GitLab CI, Jenkins）。
• revert: 撤销之前的某次提交。

3. 特殊标记与重大变更

3.1 Breaking Change (破坏性变更)

当代码更改导致 API 不兼容或需要用户进行重大调整时，必须明确标记：

• 感叹号标记: 在类型/范围后添加 !，例如：feat!: 移除对 Node.js v10 的支持。
• 页脚说明: 在正文或页脚中使用 BREAKING CHANGE: 关键词，后面紧跟关于变动的详细描述。

3.2 范围 (Scope)

范围是可选的，用于说明提交影响的具体模块。例如：feat(parser): ... 或 fix(ui): ...。

4. 为什么要遵循这套规范？

1. 自动化生成 Changelog: 可以通过工具（如 standard-version）自动根据提交记录生成版本日志。
2. 更好的协作体验: 团队成员可以一眼看出哪些提交是新功能，哪些是修复，减少沟通成本。
3. 自动触发版本发布: 结合 CI/CD 工具，可以根据提交类型自动决定是发布补丁版本（Patch）、次要版本（Minor）还是主要版本（Major）。
4. 提高搜索效率: 方便使用 git log --grep 等命令快速定位特定类型的变更。

5. 推荐工具

• Commitizen: 一个交互式工具，通过问答方式帮助你生成符合规范的提交信息。
• Commitlint: 用于检查提交信息是否符合规范，通常配合 Husky 在 git commit 时进行拦截校验。