提交前运行git diff –check，可以发现差异中新引入的空白错误和冲突标记，并在发现问题时返回非零状态。它不是编译器，也不是测试框架；检查范围还取决于你是否加入–cached。
先决定检查哪份差异
普通git diff –check查看工作区与暂存区的差异；加–cached时查看暂存区相对于默认HEAD的差异。文件已经暂存后，前一种可能没有输出，因为工作区与暂存区已经相同，而准备提交的内容仍可能有问题。
git diff --check
git diff --cached --check
在临时仓库中做一个可复现对照
本站测试先提交一份没有多余空格的note.txt，再将它改成行末有空格的新内容。未暂存时，普通检查返回非零；执行git add以后，普通检查通过，而–cached检查仍返回非零。随后去掉行末空格并重新暂存，–cached检查才通过。测试仅发生在临时仓库，没有修改真实项目。
| 状态 | 普通–check | –cached –check |
|---|---|---|
| 修改后尚未暂存 | 检测到工作区新空白问题 | 暂存区尚无该变化 |
| 同一错误内容已暂存 | 工作区与暂存区相同 | 检测到准备提交的问题 |
| 修正后重新暂存 | 通过 | 通过 |
项目规则会影响什么算空白错误
官方文档说明，规则由core.whitespace控制，默认包含行末空白等情况。阅读自动化日志时，应同时记录项目配置与命令参数。不要为了让检查变绿就悄悄放宽规则，也不要把历史文件中所有空格都当作本次新增问题。
把它放进提交检查，但不替代其他验证
本地还把示例文件改成没有空白问题、却不是有效Python代码的文本；–check仍然通过。这说明它不理解程序语义。实际交付可依次查看差异、检查空白、运行语言检查和必要测试，每一步保留各自的失败原因，不把一次通过写成“代码完全正确”。
资料来源与继续学习
资料查阅日期：2026年10月14日。示例、阅读练习与操作建议由本站整理。
资料查阅与编辑日期：2026年10月14日。作者：玖柒。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
