03 · 提交信息与提交粒度

记忆锚点：提交信息写给三个月后的自己——那时的你对现在的上下文一无所知。

一、好信息的形状

一条合格的提交信息分两段：

fix: 修复文章列表分页在最后一页重复显示的问题

列表接口在总条数恰好整除时会把最后一页请求两次，
改为在渲染层对页码去重，并补了边界用例。

• 首行：一句话说清「做了什么」，50 字以内，动词开头；
• 空一行；
• 正文（可选）：说清「为什么这么改」，背景、取舍、副作用。

只看首行就能扫懂整个历史的仓库，和一排 修改、update、111 的仓库，是两种维护体验。

二、前缀约定（Conventional Commits 精简版）

前缀	用途
feat	新功能
fix	修 bug
docs	只改文档
style	格式调整，不动逻辑
refactor	重构，行为不变
chore	构建、依赖、杂务

前缀让 git log --oneline 自带分类，也方便脚本自动生成变更日志。本站所属的仓库矩阵就在用这套约定。

三、粒度：一个提交做一件事

• 太小（每保存一次就 commit）：历史变成噪音，没人翻；
• 太大（「完成后台管理系统」一锤子提交）：想回退一小半也回退不了；
• 刚好：一个提交对应一个可独立描述的意图，回退它、讨论它、revert 它都成立。

判断标准很简单：这条提交信息能不能不带「和」「另外」。写出来是「修复分页问题并顺带升级了依赖」，就该拆成两条。

四、手滑了怎么办：修补最近一次提交

# 刚 commit 完发现漏了一个文件 / 信息写错了：
git add 漏掉的文件
git commit --amend        # 并入最近一次提交（可顺带改信息）

amend 只对还没推送的提交随便用；已推送的提交被改写后，远程历史就和本地对不上了（协作分支上这是事故，第八章讲远程协作时会再提到）。

五、动手实验

1. 翻翻你自己任何一个仓库的 git log --oneline，把信息分成「能看懂 / 看不懂」两堆，数比例；
2. 故意提交一条只有 update 的提交，一个月后试着回忆它干了什么；
3. 练习 commit --amend：补文件、改信息各来一次（在试验仓库里）。

六、本课小结

• 首行 50 字动词开头，正文讲为什么；
• 前缀分类：feat / fix / docs / style / refactor / chore；
• 一个提交一件事；--amend 只碰未推送的提交。

下一篇：分支与 HEAD：指针游戏（待写）