一次修改里面混着功能调整、格式整理和文件重命名，提交时很省事，回看时却很费力。尤其是需要撤销其中一项改动时，很难确定另一项会不会一起受影响。

按目的拆分，而不是按文件拆分

假设要修复文章页面的目录链接，同时调整首页字体。虽然都属于博客样式，但它们解决的是两个独立问题，适合分成两次提交。

反过来，一个功能可能同时涉及模板、样式和配置。这几个文件一起构成完整行为，放在同一个提交里更容易理解。

提交之前看两次差异

git status --short
git diff
git add -p
git diff --cached

第一次看全部修改，确认有没有临时调试代码或无关文件。第二次看暂存区，确认这次真正准备提交什么。git add -p 可以按片段选择，适合把同一文件里的不同目的修改分开。

尤其要注意配置文件。测试时临时写入的令牌、账号或服务器地址，不应因为顺手执行了 git add . 就进入仓库。.gitignore 也不会自动停止追踪已经提交过的文件。

提交说明写清结果

“修改代码”“修复问题”都没有留下太多线索。更有用的写法是说明触发条件和改变后的行为，例如：

修复窄屏下文章目录遮挡正文的问题

如果原因不明显，可以在正文里解释为什么这样改、有没有取舍。无需把每个文件名再抄一遍，Git 本来就记录了这些信息。

小提交也要完整

小不等于碎。一个提交最好可以独立构建或运行，不依赖下一次提交才能恢复正常。这样无论做代码审阅、定位回归还是回退，边界都更清晰。

把提交当成写给未来自己的说明：当细节已经忘记，仍然能用几分钟重新理解当时的决定。