Git Commit 规范：怎么写清楚提交信息

好的 commit message 不是写给机器看的，是写给未来的自己和同事看的。半年后出问题，git log 能不能看懂，全靠当时有没有写清楚。

推荐格式

格式只是约定，目的是让列表一眼能扫出修改类型和影响范围。个人项目可以简单一点，团队项目最好固定下来。

1
type(scope): subject

例子：

1
feat(search): add active filter chips
2
fix(article): keep progress bar below mobile header
3
docs: update writing guide

常见 type：

1
feat     新功能
2
fix      修复 bug
3
docs     文档
4
style    格式，不影响逻辑
5
refactor 重构
6
test     测试
7
chore    工程杂项

scope 可以省略，但不要为了凑格式乱写。比如只改文档，docs: 更新部署说明 就很清楚。

中文怎么写

中文项目可以写中文说明：

1
feat(search): 增加已选筛选条件标签
2
fix(article): 修复移动端阅读进度条遮挡
3
docs: 更新写作说明

type 和 scope 保持英文，后面的说明用中文，读起来很顺。

一次提交做一件事

不要这样：

1
fix: update

也不要一个提交同时改搜索、文章、部署脚本。拆开后回滚和 review 都更容易。

常见问题

提交写错了但还没 push：

1
git commit --amend

已经 push 到共享分支就别随便改历史，除非团队明确允许。

总结

commit message 重点是说明“为什么改”和“改了什么范围”。格式可以简单，但不要空泛。分支协作可以接着看 GitHub Pull Request 工作流入门，救急命令看 Git 进阶：你迟早要会的几个救急命令。