有没有遇到过这种情况：翻看之前的代码提交记录，一堆 “fix bug” 让你一脸懵逼？优秀的 Git Message 可不是随便写的备注，它是项目的时间机器，更是团队合作的秘密武器。 今天就来聊聊，怎么写出让未来的自己拍手叫好的 Git Message。
官方文档：Conventional Commits
结构要清晰：像填一份病历表
一份好的 Git Message，得把 “谁、干了啥、为啥干、咋干的” 说清楚，就像医生填病历卡：
Type(Scope): Subject
Body
Footer
- Type（类型）：这次修改的性质，比方说：
feat,fix,docs - Scope（范围）：影响了哪个模块或功能，可选项，可以是类名，文件名
- Subject（主题）：一句话概括这次修改，尽量简短
- Body（正文）：详细解释修改的原因、怎么实现的
- Footer（页脚）：关联了哪些 Issues，有没有破坏性改动
类型标签：代码的身份证
不同的修改场景，对应不同的类型标签，就像不同类型的身份证：
feat： 加新功能 (盖了间新房子)，比如 “feat: 加了用户注册功能”fix： 修 Bug (修补了漏水)，比如 “fix(auth): 修复了登录绕过漏洞”docs： 改文档 (更新了使用说明)，比如 “docs: 补充了 API 使用例子”style： 调整格式 (重新装修了下)，比如 “style: 统一了代码缩进”refactor： 代码重构 (动了大手术)，比如 “refactor: 优化了数据库查询”test： 加测试 (做了个检查)，比如 “test: 补充了用户注册的测试用例”chore： 工具维护 (换了把螺丝刀)，比如 “chore: 升级了 webpack”perf： 性能优化 (提升了速度)，比如 “perf: 优化了首页加载速度”ci： CI/CD 配置 (自动化流程)，比如 “ci: 优化了 Jenkins 构建流程”build： 构建流程 (打包方式)，比如 “build: 升级了 babel 依赖”revert： 撤销 (后悔药)，比如 “revert: 恢复之前的数据库迁移”
场景举例：照着抄就行
看看这几个常见的场景，照着写准没错：
场景 1：新增用户登录功能
feat(auth): 加了用户登录功能
- 用户可以用账号密码登录了
- 用 JWT 做了身份验证
- 登录失败会提示
Closes #123
场景 2：修复了用户头像上传的 Bug
fix(user): 用户头像传不上去了，修好了
- 之前服务器配置有问题，导致传不上去
- 改了 nginx 配置，允许上传更大的文件了
Fixes #456
场景 3：重构了支付模块
refactor(payment): 支付模块大改造
- 把支付逻辑从 Controller 搬到了 Service 层
- 代码更清晰，更好维护了
Related to #789
场景 4：删除一些不影响逻辑的杂项任务
chore: 移除无用的旧的配置文件
- 删除了不再使用的 legacy-config.js
- 减少了项目体积，简化了维护
场景 5：修改文档
docs: 删除了过时的 API 文档
删除了已废弃的 `/api/legacy` 接口的文档。
把每次代码提交当成给代码写日记： Type 是心情标签，Subject 是今天干了啥，Body 是具体经过，Footer 用于提示额外信息！这样想，写 Git Message 就是在为未来的自己铺路！
场景 6：github 分支处理
fix: 修改了分支冲突
如果就是处理一些冲突，没有涉及到功能的添加就用 fix。
feat: 添加了xxx功能
添加了功能就正常写添加了什么功能即可，可以提一嘴处理了分支。
场景 7：初始化项目
也就是第一次提交。
如果只是框架就用：
chore: 初始化项目
如果已经创建了一些功能了：
feat: 初始化项目
- 创建配置文件
- 添加核心功能
一些技巧
- 小步快跑：每次提交只改一点，别搞 “一锅烩”。
- 正文要精简：简单的改动可以省略，复杂的要写清楚。
- 工具来帮忙：用 Commitizen 之类的工具，省时省力。
- 团队要统一：大家用一样的规范，避免混乱。