每个程序员都有过这样的经历：凌晨两点，终于修完那个该死的bug，敲下 git commit -m "fix bug"，然后心安理得地去睡觉。
三天后，你打开Git日志，面对一排排的 “update”、”fix”、”改了点东西”，完全想不起自己到底干了什么。
为什么你的提交信息这么重要？
这不是在写日记，是在写代码的考古记录。
想象一下，半年后你（或者更惨，你的同事）需要排查一个线上问题。Git日志是唯一的线索。如果每条提交都是 “update”，那跟没有记录有什么区别？
好的提交信息能让你：
- 快速定位问题引入的时间点
- 理解每个改动的意图和上下文
- 减少代码评审时的沟通成本
- 自动生成有意义的变更日志
Angular提交规范：业界公认的最佳实践
目前最流行的提交信息格式来自Angular项目，结构如下：
<type>(<scope>): <subject>
<body>
<footer>type（必填）：改动类型
feat：新功能fix：bug修复docs：文档变更style：代码格式（不影响逻辑）refactor：重构test：测试相关chore：构建/工具链相关
scope（可选）：影响范围，比如 auth、api、ui
subject（必填）：简短描述，50字符以内，不用句号结尾
实战对比
糟糕的提交示例：
git commit -m "update"
git commit -m "fix bug"
git commit -m "改好了"
git commit -m "."
git commit -m "wip"优秀的提交示例：
git commit -m "feat(auth): add OAuth2.0 login support"
git commit -m "fix(api): resolve race condition in user service"
git commit -m "refactor(db): extract connection pool to separate module"
git commit -m "docs(readme): update installation instructions for macOS"
几个实用技巧
1. 使用提交模板
在项目根目录创建 .git/COMMIT_EDITMSG 模板：
# type(scope): subject
#
# body
#
# footer然后配置：git config commit.template .git/COMMIT_EDITMSG
2. 用工具强制规范
commitlint 可以在提交时自动检查格式，不合规范直接拒绝。
3. 写body时回答三个问题
- 为什么要改？
- 怎么改的？
- 有什么影响？
从今天开始改变
好的提交信息不是浪费时间，而是对未来的自己和团队负责。每次提交前，多花10秒钟想一个清晰的描述，你的未来自己会感谢现在的你。
毕竟，没有人想在凌晨三点的生产环境排查中，面对一堆 “update” 欲哭无泪。
你见过最离谱的Git提交信息是什么？欢迎在评论区分享。
觉得有用就点个赞吧~