Git 提交规范：写好每一次 commit
很多项目的 Git 历史看起来都差不多：
update
fix bug
改一下
临时提交
这些提交在当下可能能看懂，但过几天再回头看，基本就不知道当时到底改了什么。
所以我觉得，commit message 不只是给 Git 看的，更是给未来的自己和队友看的。
为什么要规范 commit？
规范 commit 最大的价值不是“显得专业”，而是降低沟通成本。
当你看到这样一条提交：
fix(login): 修复登录过期后未跳转的问题
你不用打开代码，也能大概知道这次修改的目的。
它至少解决了三个问题：
- 方便回溯历史
- 方便 Code Review
- 方便团队协作
如果后续接入 changelog、自动发版之类的工具，规范的 commit message 也会更容易处理。
我推荐的格式
比较常见的写法是 Conventional Commits：
<type>(<scope>): <subject>
比如：
feat(auth): 新增邮箱验证码登录
fix(form): 修复表单校验失效问题
docs: 更新 README 使用说明
refactor(api): 重构请求封装逻辑
其中：
type表示提交类型scope表示影响范围，可以不写subject表示这次提交做了什么
如果项目比较小，也可以先用简化版：
<type>: <subject>
比如：
feat: 新增文章搜索功能
fix: 修复移动端菜单无法关闭的问题
常用 type
日常开发里，用下面几个基本就够了：
| type | 含义 |
|---|---|
| feat | 新增功能 |
| fix | 修复问题 |
| docs | 文档修改 |
| style | 代码格式调整 |
| refactor | 代码重构 |
| perf | 性能优化 |
| test | 测试相关 |
| build | 构建相关 |
| ci | CI/CD 相关 |
| chore | 其他杂项 |
刚开始不需要追求太复杂，能把 feat、fix、docs、refactor、chore 用清楚，就已经比大多数随手提交好很多。
不推荐的写法
下面这些提交信息尽量不要再用了：
update
fix
bug
修改
提交
111
final
它们的问题不是“不规范”，而是信息量太低。
一条好的 commit message 应该让别人看完之后知道：
这次提交到底改了什么？
比如：
fix: 修复搜索结果为空时页面报错
feat: 新增文章标签筛选功能
docs: 补充本地开发环境说明
这些就比简单的 update 清楚很多。
一次 commit 只做一件事
除了 message 格式，提交粒度也很重要。
推荐这样拆：
feat(login): 新增验证码登录功能
fix(login): 修复验证码倒计时异常问题
style(login): 调整登录页按钮间距
不要把新增功能、修 bug、改样式、重构代码全部塞进一个 commit。
这样做的好处是：
- Review 更容易
- 出问题时更容易回滚
- 查看历史时更容易理解
我的建议
如果是个人项目，我建议先做到这三点：
- 不再写
update、fix bug、改一下 - 使用
type: 描述的格式 - 一次 commit 尽量只做一件事
如果是团队项目，可以再加上 scope，并配合 commitlint、husky 这类工具做自动校验。
总结
Git 提交规范不是为了让流程变复杂，而是为了让项目历史更清楚。
写好 commit message，其实是在帮未来的自己省时间。
从最简单的格式开始就够了：
feat: 新增功能
fix: 修复问题
docs: 更新文档
refactor: 重构代码
chore: 日常维护
别再写 update 了。