规范Git commit

背景

Git 要求每次提交必须填写 Commit Message。规范的提交信息应清晰阐明提交目的与具体变更内容。然而，日常开发中常出现提交信息随意的问题，如中英文混杂、语义模糊（如仅写 "fix bug"），导致后续代码维护难度陡增，甚至开发者自身也难以追溯历史修改。为提升代码质量和研发效率，亟需建立并监控 Commit Message 规范。

规范建设

规范梳理

Commit Message 格式

<type>(<scope>): <subject>

1. type (必须) 用于标识提交类型，仅允许使用下列预设标识：

• feat: 新增功能 (feature)
• fix/to: 修复 Bug
  • fix: 直接修复问题，并产生代码差异 (diff)
  • to: 标记待修复问题 (仅产生 diff)，适用于多次提交。最终修复时用 fix
• docs: 文档更新 (documentation)
• style: 代码格式调整 (不影响功能运行的变动，如空格、缩进)
• refactor: 代码重构 (非新增功能，也非修复 Bug)
• perf: 性能优化 (performance)
• test: 补充测试用例
• chore: 构建流程或辅助工具变更
• revert: 回滚到先前版本
• merge: 代码合并
• sync: 同步主线或分支的 Bug 修复

2. scope (可选) 说明提交影响的范围 (如模块、组件、层)。例如：auth, user-service, DAO, Controller。若影响多个范围，可用 * 表示。

3. subject (必须) 提交目的的简明描述：

• 长度：不超过 50 个字符
• 语言：建议使用中文 (表述更清晰)
• 格式：结尾不加句号或其他标点

格式示例：

fix(DAO): 用户查询结果缺少 username 属性 feat(Controller): 新增用户查询接口

规范价值

推行此规范可带来显著收益：

1. 提升可追溯性：清晰的提交历史便于理解代码变更脉络。
2. 促进原子提交：约束信息格式促使开发者进行更精细、目的明确的提交，避免混杂变更。
3. 自动化支持：格式化信息可直接用于生成变更日志 (Change Log)。