Git 提交信息别只写 update
· 阅读需 3 分钟
刚开始接触 Git 时，很多人最自然的提交信息就是 update、fix bug、change 这种短句。我自己早期也这么写过，因为那时候觉得重点是“先提交上去”，信息只是顺手带一句。但真把代码历史翻回来看时，就会立刻意识到这种写法几乎没有帮到未来的自己。
提交信息不是为了交差，它其实是在给后面的排查、回滚和协作留上下文。
为什么 update 这种词几乎没价值
因为它没有回答最关键的问题：
- 改了什么
- 为什么改
- 影响范围大概在哪
你今天当然知道这次提交在做什么，但一周后、一个月后，项目再多几个分支和需求，这种信息就只剩“我确实动过一些文件”这种空话。
我后来更在意的不是长短，而是可检索
一条提交信息不一定要写成小作文，但至少要让人能从历史列表里看出方向。
比如是修接口参数、调登录状态、改页面布局，还是补部署脚本。这些词一出现，后面用 git log 或平台搜索时，命中率会高很多。
小团队里尤其明显。很多时候找问题，不是先看代码，而是先翻最近几次提交在碰什么。如果历史全是 update，排查就会被迫回到逐个 diff 硬看。
我比较认同的一条最小规则
一条提交信息至少该包含两个元素：
- 动作
- 对象
例如：
- 调整登录页表单校验
- 修复搜索接口分页参数
- 补充部署脚本环境变量说明
这样写没有很复杂，但已经比 update 有意义得多。
为什么这件事在 2013 年的小项目里也值得做
很多人觉得规范提交信息是大团队才需要的东西。
我后来反而更觉得，小项目更需要。因为小项目经常没有完整文档，代码历史本身就承担了大量“发生过什么”的说明责任。
你不认真写提交信息，等于主动放弃了一份最便宜的项目记录。
小结
Git 真正让人舒服的地方，不只是能回滚，而是能看懂自己一路做过什么。
提交信息别只写 update，不是为了显得专业，而是为了让未来的自己和后来接手的人少猜很多次。越早养成这个习惯，代码历史越像资产，而不是噪音。