别再让你的 Git History 一堆乱码了
以前写代码，我的 Git Commit 极其随性。心情好时写个 Update，心情差时直接 ... 或者 fix。
当时觉得没什么，直到前阵子回溯代码找 Bug，看着满屏毫无意义的提交记录，我陷入了深深的沉思：“这一坨到底写了啥？”
为了不让未来的自己继续崩溃，我简单整理了一下 Git Commit 规范。
这不只是为了美观，更是为了让代码变更有迹可循。
随手写带来的问题
随手写的 Commit 会带来几个很现实的问题：
- 找代码像大海捞针：想找某个功能是什么时候上线的，得一个个看
Diff。 Changelog全靠手写：版本发布时，根本记不清这两周改了什么。- 团队沟通成本高：同事看你的提交记录跟看天书一样。
现在遵循的格式
目前主流且最科学的格式是 Conventional Commits：
bash
<type>(<scope>): <subject>
<body>
<footer>核心在于 type（提交类型）
我给自己定了个规矩，每次提交前先在脑子里过一遍这个清单：
- ✨ feat: 哪怕是加个小按钮，只要是新功能就用它。
- 🐛 fix: 专门留给 Bug 修复。
- 📝 docs: 只改文档（README、注释）。
- 💄 style: 格式调整，不影响逻辑（空格、缩进等）。
- ♻️ refactor: 重构代码，既不是新功能也不是修复。
- ⚡️ perf: 优化性能的专属标签。
- 🧪 test: 补测试用例。
- 🔧 chore/build/ci: 那些跟业务逻辑无关的琐事（改配置、升依赖）。
写 Commit 的几个好习惯：
- 用祈使语气：是
fix: 修复而不是fixed: 修复了。 - 保持原子性：一个 Commit 只干一件事。别把“加功能”和“改错别字”揉在一起。
自动化工具的配置
如果全靠手动输入，难免会有偷懒的时候。我配置了一套自动化组合拳，强制自己遵守规范。
- Commitizen：把
git commit变成选择题。它会问你是什么类型、改了哪，最后帮我拼出规范的文字。 - Husky + Commitlint：这是一道“安检”。如果我的提交信息不符合规范，在
git commit的瞬间就会报错，直接拒绝提交。
我的 .commitlintrc.js 极简配置：
javascript
module.exports = {
extends: ['@commitlint/config-conventional'],
};常见问题处理技巧
规范是死的，人是活的。实际操作中总会遇到尴尬时刻：
- 写错字了？ 趁还没 Push，赶紧
git commit --amend抢救一下。 - 想看漂亮的轨迹？ 试试
git log --oneline --graph，那种整齐划一的感觉真的治愈强迫症。 - 实在紧急？ 偶尔用
--no-verify跳过校验，但记得事后别养成依赖。
总结
刚开始切换到这套规范时，确实觉得有点繁琐。但坚持一周后，我发现自己在写 Commit 的时候，实际上是在强迫自己梳理这次代码变动的逻辑。
如果你也在维护长期项目，强烈建议从下一次 git add . 开始，试着写一个标准的 feat: 或 fix:。