写完一段代码之后，先别急着提交。停下来想一想：这次改动，能不能用一句话说清楚？如果需要连续说几个“还有”，通常就值得再拆一下。
按目的拆分，而不是按文件拆分
一次提交可以改动多个文件，只要它们服务于同一个目的。例如“为文章列表补充空状态”，可以同时包含页面逻辑和对应样式。反过来，一个文件里的格式调整和业务修复，也可以属于两次提交。
比较稳妥的顺序是：先整理必要的结构，再实现行为，最后处理与行为无关的小修饰。每一步都应尽量保持项目可运行，避免出现只有最后一次提交才能工作的中间状态。
提交前，读一遍自己的改动
git status --short
git diff
git diff --staged先检查工作区，再检查暂存区。重点留意调试输出、临时文件、误改的配置，以及不属于这次任务的内容。提交前的这几分钟，经常比事后的排查更省时间。
写清楚这次改变了什么
“更新代码”很难提供线索，“为空文章列表增加提示”则更容易理解。标题描述结果，正文在必要时解释原因和限制。无需写成长篇报告，只要让后来的人知道这次选择的背景。
一个小习惯：在提交之前，试着给这次改动起一个准确的名字。名字不好起，往往是边界还不够清楚。