在多人协作的Git项目中，每次提交代码时写一个清晰的提交信息（commit message）非常重要。它不仅能帮助团队成员快速理解这次提交的内容，还能在后续通过工具自动生成版本日志（比如 standard-version），甚至在排查问题时节省时间。但如果提交信息混乱或不规范，比如“修复bug”“改了点东西”，就很难追溯变更的目的和影响。
Angular风格的提交规范基本格式¶
Angular风格的commit message分为三部分：Header（标题）、Body（正文）、Footer（页脚）。其中Header是必须的，Body和Footer可选。整体结构如下：
<type>(<scope>): <subject>
[body]
[footer]
1. Header（标题）：简洁描述变更核心¶
Header格式为：type(scope?): subject
- type（类型）：必须从以下列表中选择，用于明确变更性质：
feat：新功能（feature）fix：修复bugdocs：文档更新style：格式调整（不影响代码逻辑，如空格、换行、缩进）refactor：代码重构（既非新增功能也非修复bug）perf：性能优化test：测试相关（添加/修改测试代码）-
chore：其他不影响代码逻辑的变更（如构建脚本、依赖管理） -
scope（范围，可选）：指定变更影响的模块或功能区域（如
login、api、home），若不明确可省略。 -
subject（主题）：简短描述变更内容，需以祈使句开头（如“Add”而非“Added”），不超过50字符，结尾不加句号。
示例：¶
feat(login): add "Remember Me" option // 类型：新功能，范围：login模块，主题：添加“记住我”选项
2. Body（正文）：详细说明变更细节¶
Body用于补充说明为什么做这个变更及具体实现内容，需另起一行，并用空行与Header分隔。可写多行，每行简洁描述关键点。
示例：¶
feat(login): add "Remember Me" option
- 新增“记住我”复选框，勾选后下次登录自动填充账号密码
- 使用加密存储token和账号信息，避免明文泄露
3. Footer（页脚）：标记特殊信息¶
Footer可选，用于说明不兼容变更（Breaking Changes）或关闭Issue，同样用空行与Body分隔。
（1）不兼容变更（Breaking Changes）¶
若提交包含破坏性变更（如API接口修改），需在Footer中以BREAKING CHANGE:开头，明确描述影响范围。
示例：¶
fix(api): correct user info response format
BREAKING CHANGE: 原 `/api/user/profile` 返回的 `{name: string}` 改为 `{username: string}`，旧调用方需同步更新。
（2）关闭Issue¶
若本次提交解决了某个Issue，可在Footer中用Closes #Issue编号格式关联。
示例：¶
fix(checkout): resolve payment timeout bug
Closes #123 // 关闭编号为123的Issue
完整示例集合¶
以下是不同场景的完整提交信息示例：
示例1：新功能（feat）¶
feat(home): add search component
- 新增顶部搜索栏，支持关键词实时搜索
- 绑定后端接口，返回匹配结果列表
示例2：修复bug（fix）¶
fix(auth): resolve token expiration issue
- 修复token过期后未自动刷新的问题
- 添加本地缓存过期时间检查，延长token有效期至7天
示例3：带破坏性变更（BREAKING CHANGE）¶
refactor(api): remove deprecated /v1/user/list endpoint
BREAKING CHANGE: 废弃 `/v1/user/list` API，所有调用方需迁移至 `/v2/user/list`。
示例4：关闭Issue¶
docs: update contribution guide
Closes #45 // 解决#45号Issue中“文档缺失”问题
工具辅助规范提交信息¶
手动写易出错，推荐使用工具自动生成规范提交信息：
-
Commitizen（cz-cli）：交互式命令行工具，引导填写规范信息。
安装：npm install -g commitizen
使用：在项目根目录执行commitizen init cz-conventional-changelog --save-dev，之后用npm run commit代替git commit，按提示选择即可生成规范信息。 -
commitlint：校验提交信息是否符合规范，配合
husky在提交前自动拦截不规范信息。
注意事项¶
- type必须规范：只能用指定类型（如
feat而非“new”）。 - subject简洁明确：以动词开头（如“Add”“Fix”），避免冗余描述。
- Body按需填写：简单变更可省略Body，但复杂逻辑需说明“为什么改”。
- Footer的Breaking Changes需明确：破坏性变更必须单独列出，避免后续开发踩坑。
总结¶
规范的Git提交信息能让项目协作更高效，帮助团队快速理解代码变更，也便于工具自动生成版本日志。Angular风格是目前最通用的规范，从下一次提交开始，试着用清晰的格式写commit message吧！养成习惯后，你会发现追溯问题、协作沟通都会更顺畅～