给小项目加一道提交前检查：Git 钩子与轻量清单的落地做法

很多小项目的问题不是技术太难，而是提交太随意：调试代码忘了删、格式一团糟、提交信息只写两个字，过两周连作者自己都看不懂。解决办法不必上重型流程，给仓库加一道轻量提交前检查就够了。

先想清楚：检查要拦什么

提交前检查不是代替测试，而是把低级错误挡在仓库外面。最值得先拦的三类问题是：明显不能进仓库的内容，例如调试输出、临时文件和本地密钥；格式问题，例如行尾空格、缺少换行；信息缺失问题，例如提交信息为空，或者一次提交混进了互不相关的改动。

这些问题发现得越晚，修复成本越高。写代码时顺手改掉只要几秒，推到远端、被别人拉下来之后再返工，就要反复沟通和重新验证。钩子的价值就在这里：它把提醒放在最容易改正的时刻。

钩子放在哪里

Git 的 pre-commit 钩子会在提交创建之前运行，检查失败就阻止提交，检查通过才继续。实现上不需要依赖框架：仓库里放一个检查脚本，钩子负责调用它即可。脚本可以先做文件名过滤，再做内容扫描，最后做格式检查，任何一步失败都打印清楚的原因并退出。

一个实用原则是：钩子只做快速检查。能在三秒内跑完的检查都可以放进来，例如扫描敏感词、检查文件编码、统一行尾。需要联网、耗时较长的检查不适合放在钩子里，否则每次提交都要等很久，大家很快就会想办法绕过它。

一张够用的最小清单

清单越短，执行率越高：提交前看一遍改动文件列表，确认没有临时文件；删除调试用的打印语句；提交信息写清楚改了什么和为什么改；一次提交只做一件事；改动涉及配置或依赖时，顺手更新说明文档。

清单可以直接写在钩子的失败提示中，因为提示出现在提交失败的当下，比事后翻文档更容易被看到。例如发现调试语句时，直接告诉用户文件名和行号，而不是只说检查失败。

小结

小项目的提交质量不需要复杂工具：一道快速的提交前检查，加上一张五条左右的清单，就能挡住大部分低级错误。先从调试语句、临时文件和提交信息做起，跑顺了再逐步扩展；当检查开始拖慢提交时，就说明它该瘦身了。