你有没有遇到过这种情况——git log 一看，满屏的 fix、update、改了点东西，根本不知道每次提交到底干了什么。三个月后自己都看不懂自己写的啥🥲
今天笔笔就来聊聊，怎么写一条清晰、有用、不被同事打的 Commit Message。
1. 为什么提交信息很重要？
一个项目的 Git 历史就像一本日记。好的提交信息能让你：
- 快速定位 bug：用
git bisect时一眼知道哪个 commit 引入了问题 - 生成 Changelog：有条理的提交可以直接用脚本生成发布说明
- Code Review 更顺畅：reviewer 知道你想做什么，而不是对着 diff 瞎猜
💡 "A well-crafted Git commit message is the best way to communicate context about a change to fellow developers." —— 某位被同事代码逼疯的工程师
2. 推荐的格式
业界比较流行的「约定式提交」（Conventional Commits）长这样：
<type>(<scope>): <subject> <body> <footer>
其中 type 是最关键的，常用取值如下：
- feat：新功能 ✨
- fix：修 bug 🐛
- docs：文档变更 📝
- style：格式调整（不影响逻辑）🎨
- refactor：重构（既不加功能也不修 bug）🔧
- perf：性能优化 ⚡
- test：测试相关 🧪
- chore：构建 / 工具链变动 🔩
3. 举个例子
❌ 反例（千万别这样写）：
git commit -m "fix"
✅ 正例：
feat(auth): 新增 GitHub OAuth 登录 使用 passport.js 集成了 GitHub OAuth2 流程， 用户现在可以用 GitHub 账号一键登录。 Closes #42
这个提交一看就懂：在 auth 模块加了一个 GitHub 登录功能，关联了 issue #42。
4. 几个小建议
- 标题用英文祈使句，首字母小写，不加句号
- 标题控制在 50 字以内（中文约 25 个字）
- 标题和正文之间空一行
- 正文解释 做了什么 和 为什么这么做，而不是怎么做的（代码已经说明了怎么做的）
- 关联 issue 用
Closes #xxx或Refs #xxx
5. 总结
写好 Commit Message 不需要太多时间，但收益巨大。花 30 秒把 fix 写成 fix(parser): 修复 Markdown 代码块解析异常，你的同事会在心里给你默默点赞👍
当然，更重要的是——三个月后的你自己也会感谢你。