提交越小不一定越清楚。把一个完整修复拆成不能独立工作的碎片，同样增加审查难度。
本文使用Git 2.x 与独立演示仓库。Git（分布式版本管理）保存提交对象和引用，工作区、暂存区与提交历史不是同一份状态。每次操作先判断它改变哪个区域，再决定是否适合当前协作情境。
1. 从现象推到机制
合理提交应有单一目的、可解释差异和完整依赖。格式化、重命名与行为修改混在一起，会掩盖真正逻辑；但接口和调用方的必要同步不宜拆成中间不可构建状态。
图中的四个节点分别表示业务意图、暂存审查、独立提交、维护阅读。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
提交前先按意图检查暂存差异，确认没有临时日志和无关资源。说明问题、改变的行为与验证方法，避免只写“update”。
1
2
3
4
git diff --stat
git diff --check
git diff --cached
git commit -m "Handle empty order result in demo list"
示例在没有私人资料的临时仓库执行。先看 status、diff 与 log，再运行改变状态的命令；共享历史优先新增提交表达修复，不用改写历史掩盖已经发生的变化。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 格式化与规则修改混合 | 审查者难以找到业务变化 |
| 接口变更未带调用方 | 中间提交可能不可运行 |
| 只记录修改文件名 | 难以恢复改动原因 |
对照 1：格式化与规则修改混合
审查者难以找到业务变化。观察时记录无关行数与实际逻辑差异。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：接口变更未带调用方
中间提交可能不可运行。观察时记录构建与最小调用场景。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：只记录修改文件名
难以恢复改动原因。观察时记录提交说明是否表达问题与结果。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
提交说明应服务未来维护，不是重复代码。涉及必要取舍时保留原因，临时探索过程则不必全部写进永久历史。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“只记录修改文件名”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
