概述

良好的提交规范有助于：

• 生成清晰易懂的提交历史
• 自动生成变更日志（CHANGELOG）
• 提高代码审查效率
• 便于追踪代码变更原因
• 支持自动化版本管理

提交格式

标题行

格式：<type>(<scope>): <subject>

• type（类型）：提交的类型
• scope（范围）：可选，说明提交影响的范围
• subject（主题）：简短的描述，不超过50个字符

提交类型

范围（Scope）

范围应该是描述被修改部分的名词，例如：

• feat(auth): 认证相关功能
• fix(ui): 用户界面修复
• docs(readme): README文档更新
• refactor(api): API相关重构

对于小型项目或难以定义范围的情况，可以省略范围部分。

主题（Subject）

• 使用祈使句，现在时态："change" 而不是 "changed" 或 "changes"
• 首字母不大写
• 结尾不加句号
• 简洁明了，说明提交做了什么

示例

简单提交

feat: 添加 xxx 功能

fix: 修复 xxx 导致的 bug

docs: 更新 README

带范围的提交

feat(auth): 添加 OAuth2.0 支持

fix(api): 修复 CurseForge API 变更带来的 bug

refactor(router): 重构路由配置结构

最佳实践

1. 每个提交只做一件事：一个提交应该只包含一个逻辑变更
2. 提交前测试：确保提交的代码可以正常构建和运行
3. 使用描述性信息：让他人能够理解提交的目的
4. 保持提交原子性：便于回滚和代码审查
5. 定期提交：避免大量代码集中在一次提交中

工具支持

提交验证

所有提交请务必带有 GPG/SSH 签名验证

自动化生成变更日志

符合此规范的提交历史可以用于自动生成变更日志：

• standard-version: 自动版本管理和变更日志生成
• conventional-changelog: 从提交历史生成变更日志

例外情况

在某些情况下，可以灵活应用此规范：

1. 合并提交：使用简单的描述，如 "Merge branch 'feature/login'"
2. 初始提交：可以使用 "Initial commit" 或 "chore: initial commit"
3. 紧急修复：在确保信息可理解的前提下，可以简化格式