Git commit message规范：让团队协作更高效

在日常开发中，我们经常会用Git进行版本控制。每次提交代码时，写一个清晰的提交信息（commit message）其实非常重要。但很多初学者可能觉得”随便写几句就行”，但实际上，不规范的提交信息会给团队协作带来很多麻烦。

为什么需要规范的commit message？¶

想象一下：

团队里有10个人，如果每个人的提交信息都写得很随意（比如“改了点东西”、“修复一下”），过两周后你想知道某个bug是谁提交的，却发现所有提交都一样，根本没法追踪。
如果你需要向别人解释这个项目的更新历史，比如“这是一个大版本升级”，但提交信息全是零散的改动，根本理不清逻辑。

规范的commit message就像给每一次代码提交写一个“说明书”，让团队成员能快速理解这次提交做了什么，方便协作、问题追踪和版本管理。

规范的commit message长什么样？¶

目前最流行的规范是Conventional Commits（约定式提交），它基于Angular项目的提交规范，已经成为行业标准。简单来说，规范的commit message可以分为几个部分：

<类型>[可选作用域]: <简短描述>

[可选正文（详细说明）]

[可选脚注（关联Issue或破坏性变更）]

1. 类型（Type）：说明提交的性质¶

类型是必填的，它告诉别人这次提交是“新功能”、“修复bug”还是“改文档”等。常见类型有：

feat：新功能（Feature），比如添加一个按钮、新接口等。
fix：修复bug，比如修复某个页面显示错误。
docs：文档相关，比如更新README或注释。
style：格式调整（不影响代码逻辑），比如改缩进、加空格。
refactor：重构代码（既不是新功能也不是修复bug），比如优化函数结构。
test：添加或修改测试代码。
chore：琐事，比如更新依赖、修改构建脚本。

例子：
feat(用户模块): 添加登录验证码功能

2. 作用域（Scope）：可选，限定提交的范围¶

作用域是可选的，用来指明提交影响的代码模块或功能范围。比如项目里有“用户模块”、“购物车模块”、“支付模块”等，加上作用域能更精准定位。

例子：
fix(购物车): 解决结算时商品数量为0的报错

3. 描述（Description）：简短说明提交内容¶

描述是必填的，要简洁明了，说明这次提交做了什么。通常用祈使句，比如“添加”、“修复”、“优化”等。

例子：
feat(用户模块): 添加登录验证码功能
（描述部分直接说“添加登录验证码功能”）

4. 正文（Body）：详细说明（可选）¶

如果描述不够，正文可以详细解释提交的目的、原因或实现方式。比如为什么要做这个改动，解决了什么问题。

例子：

feat(用户模块): 添加登录验证码功能

之前的登录逻辑只有密码，容易被暴力破解。现在添加了短信验证码和邮箱验证码两种方式，提高安全性。

5. 脚注（Footer）：关联Issue或破坏性变更（可选）¶

脚注可以用来关联项目的Issue（比如修复了哪个问题），或者说明破坏性变更（Breaking Change）。

破坏性变更：如果提交会影响现有代码逻辑（比如API接口参数变化），需要在脚注中说明。
关联Issue：比如 Closes #123 表示这个提交解决了#123号Issue。

例子：

fix(用户模块): 修复登录失败导致的无限循环

当用户连续输错密码时，系统没有限制尝试次数，导致死循环。现在添加了5次失败后锁定账号的逻辑。

Closes #456

规范的commit message模板和示例¶

模板格式：¶

<type>[可选作用域]: <简短描述>

[可选正文]

[可选脚注]

示例1：新功能（feat）¶

feat(支付): 添加微信支付功能

支持用户使用微信扫码支付，提高支付渠道。

Closes #78

示例2：修复bug（fix）¶

fix(购物车): 解决结算时商品重复计算的问题

之前用户多次添加同一商品时，结算金额会重复累加。现在修复了数量计算逻辑，确保每个商品只算一次。

Fixes #123

示例3：破坏性变更（Breaking Change）¶

feat(api): 新增用户查询接口

新增了 /api/user/list 接口，但旧接口 /api/users 已废弃，调用方需升级到新接口。

BREAKING CHANGE: 废弃旧接口 /api/users，新接口返回格式调整为...

如何养成规范写commit message的习惯？¶

1. 记住常用类型¶

feat（新功能）、fix（修复）、docs（文档）、chore（琐事）是最常用的。

2. 使用工具辅助¶

commitizen：交互式命令行工具，让你一步步选择类型、作用域和描述，避免手动写规范。
安装：npm install -g commitizen
使用：git cz 代替 git commit，跟着提示填写。
commitlint + husky：自动检查提交信息是否符合规范，提交前拦截不符合规范的信息。

规范带来的好处¶

团队协作更高效：成员能快速理解提交内容，不用翻代码就能知道这次改了啥。
自动生成版本日志：工具（如standard-version）能根据commit message自动生成ChangeLog，直接对应版本更新内容。
问题追踪更清晰：通过 Closes #123 直接关联Issue，提交和问题一一对应。
破坏性变更提前预警：破坏性变更明确标注，避免影响其他模块。

总结¶

规范的commit message不是强制要求，但养成这个习惯能极大提升团队协作效率。记住核心原则：类型+描述+必要细节，写清楚“这次提交是干嘛的，为什么这么做”。刚开始可能需要刻意练习，但熟练后会发现好处远超投入的时间。

现在，下次提交代码时，试着用规范的格式写一条信息吧！