为什么需要统一的提交规范？¶
在团队协作中，每次修改代码后都要写Git提交信息（Commit Message）。如果大家提交信息写得乱七八糟，比如“改了一下”“修了个bug”，会带来很多问题：
- 代码审查困难：别人不知道你具体改了什么，要花时间看代码才能理解
- 版本迭代混乱：版本历史看不懂，不知道某次提交是新增功能还是修复问题
- 自动化工具失效：像生成版本日志、自动关联Issue等工具可能无法工作
统一的提交规范就像给每次修改“贴标签”，让大家一眼就能看懂这次改动的目的和内容。
第一步：理解提交信息的规范格式¶
目前最流行的规范是 Conventional Commits，它把提交信息分成几个清晰的部分：
<类型>[可选作用域]: <描述>
[可选正文]
[可选脚注]
1. 类型（type）：告诉别人这次提交的“性质”¶
类型必须是以下几种之一，选错会误导版本迭代：
feat：新增功能（比如“添加用户登录按钮”）fix：修复bug（比如“修复购物车结算时金额计算错误”）docs：文档相关（比如“更新API文档说明”）style：格式调整（不影响代码逻辑，比如改缩进、空格）refactor：代码重构（既不是新增也不是修复，比如优化算法）test：添加/修改测试代码chore：其他杂项（比如改配置文件、依赖版本）
示例：feat: 新增用户注册页面
2. 描述（description）：简洁说明改动内容¶
- 要简短（一般不超过50字），但必须清晰
- 以动词开头（比如“添加”“修复”“优化”）
- 不能用疑问句或感叹句，直接陈述事实
错误：改了页面布局（太模糊）
正确：优化首页导航栏布局（明确改了哪里）
3. 正文（body，可选）：详细解释改动细节¶
如果描述不够清楚，可以用空行隔开正文部分，详细说明：
- 为什么做这个改动
- 具体实现了什么功能
- 解决了什么问题
示例：
fix: 修复移动端菜单点击无反应
- 移动端菜单按钮绑定的点击事件未触发
- 检查发现是事件委托的选择器错误
- 已修改为正确的子元素选择器
4. 脚注（footer，可选）：关联问题或说明影响¶
- 可以关联Issue（比如
Closes #123表示修复了编号123的问题） - 如果有破坏性改动（比如API变更），需要用
BREAKING CHANGE:开头说明
示例：
feat: 添加用户权限管理功能
- 支持管理员/普通用户角色区分
- 新增权限校验中间件
Closes #456 // 关联开发计划中的任务
第二步：创建团队提交模板¶
方法1：全局配置（所有项目通用）¶
- 创建模板文件：在电脑中新建一个文本文件（比如
.gitmessage），放在用户根目录（Windows是C:\Users\用户名，Mac/Linux是~），内容如下：
# 提交信息模板
## 类型（必填）：
- feat: 新增功能
- fix: 修复bug
- docs: 文档更新
- style: 格式调整
- refactor: 代码重构
- test: 测试相关
- chore: 其他杂项
## 描述（必填，不超过50字）：
[用动词开头描述改动内容，例如：添加用户注册功能]
## 正文（可选，多行）：
[详细说明改动原因、实现细节或测试情况]
## 脚注（可选）：
- 关联Issue: Closes #编号
- 破坏性改动: BREAKING CHANGE: [说明]
- 配置Git使用模板：打开终端，执行以下命令：
git config --global commit.template ~/.gitmessage
以后每次执行git commit时，Git会自动打开模板文件，方便填写。
方法2：项目级模板（仅当前项目使用）¶
如果团队有特定规范，或者项目需要单独配置，可以在项目根目录新建.gitmessage文件，内容同上。然后在项目内执行：
git config commit.template .gitmessage
这样只有当前项目会使用这个模板，避免影响其他项目。
第三步：使用模板提交代码¶
快速提交（单行信息）¶
如果改动简单，直接用-m参数写提交信息：
git commit -m "feat: 修复登录按钮样式"
详细提交（使用模板）¶
如果改动复杂，会自动打开编辑器（比如Vim），显示模板内容，按规范填写即可：
git commit
填写完后保存退出（Vim中按ESC，输入:wq回车）。
工具辅助：强制规范提交信息¶
为了让团队成员严格遵守规范，推荐使用工具自动检查：
1. Commitlint：检查提交信息是否符合规范¶
- 安装：
npm install --save-dev @commitlint/cli @commitlint/config-conventional - 配置：在项目根目录新建
commitlint.config.js，内容：
module.exports = {extends: ['@commitlint/config-conventional']}
- 使用：在提交前，Commitlint会自动检查信息格式，不符合则报错。
2. Husky：在提交前触发检查¶
Husky是Git钩子工具，能在提交、推送等操作前执行脚本。配合Commitlint，在提交前强制检查：
- 安装：npm install husky --save-dev
- 初始化：npx husky install
- 添加钩子：npx husky add .husky/commit-msg 'npx --no -- commitlint --edit $1'
这样提交时如果信息不规范，就会被拦截，无法提交。
常见错误和注意事项¶
- 类型选错：比如把
fix写成chore，导致版本日志不准确 - 描述太模糊：比如只写“改了bug”，别人不知道改了哪里
- 正文冗余：不需要重复代码里已经写清楚的内容
- 关联Issue不完整：应该写
Closes #123而不是只写#123
正确示例：
fix: 修复购物车数量计算错误
- 当商品数量为0时，结算按钮未隐藏
- 检查发现是条件判断逻辑错误（>=0 应为 >0）
Closes #789 // 关联具体问题编号
总结¶
规范的提交信息就像给每次代码改动写“说明书”，能让团队协作更顺畅。记住：类型明确、描述清晰、正文简洁、脚注关联，是写出好提交信息的核心。即使是个人项目，养成规范提交的习惯也能让自己后续维护代码更轻松。
如果团队已经用惯了模板，记得把.gitmessage和工具配置（Commitlint/Husky）共享给所有人，一起养成良好的开发习惯！