Git hooks使用技巧

先简单说下Git hooks是啥。它本质是Git仓库里的一组脚本，藏在.git/hooks目录下，分客户端和服务器端两种。客户端 hooks 主要在本地操作时触发，比如提交、合并、推送这些；服务器端则影响远程仓库，比如接收推送时的检查。默认情况下，这些脚本样例文件都带.sample后缀，想用的话，去掉后缀改成可执行文件就行。我最初用的时候，发现它特别适合处理那些容易忘的琐碎任务，比如代码格式化或依赖更新。

第一个实用技巧是定制pre-commit hook来自动化代码检查。我以前总犯懒，提交前不跑ESLint，结果代码库慢慢积了一堆格式问题。后来写了个简单的pre-commit脚本，每次git commit前自动执行lint检查。具体做法是：在.git/hooks/pre-commit文件里写个bash脚本，调用项目的lint命令。如果检查失败，脚本就返回非零状态，Git会自动终止提交。这样逼得我每次提交前都得把代码整理干净，久而久之，团队里的代码质量明显上来了。不过要注意，别在脚本里塞太重的任务，否则提交会慢得让人抓狂。

另一个我常用的技巧是用pre-push hook做集成测试。在大型项目里，光跑单元测试不够，有时本地测试通过了，但一推送到远程就和别人代码冲突。我在pre-push里加了调用测试套件的命令，比如用pytest或JUnit跑一遍核心流程。脚本会检查测试结果，如果有失败就阻止推送，并打印错误日志。这招帮我避免了好多半夜被紧急电话叫醒修bug的惨剧。当然，测试得写得够快，不然每次推送等半天，团队该抱怨了。

对于需要自定义环境的场景，我还会用post-merge hook处理依赖更新。比如团队用Node.js项目时，package.json经常更新。我在post-merge里写了个脚本，每次git pull或merge后，自动跑npm install，确保本地依赖永远最新。这特别适合多分支开发的情况，减少那种“我本地好好的啊”的经典扯皮。实现起来简单，就几行代码检查package.json的变更时间，然后触发安装命令。

除了这些，Git hooks还能玩出花样，比如用commit-msg hook校验提交信息格式。我们团队规定提交信息必须带JIRA任务号，我就写了个脚本用正则表达式检查commit message，如果不符合格式，直接拒绝提交。这强迫大家养成好习惯，后期查历史记录方便多了。不过得小心，脚本别写太复杂，万一正则出bug，所有人都卡住了。

最后提醒几个坑：Git hooks默认只在本地生效，不会跟着仓库传播，所以每个队友都得自己配置。如果想团队统一，可以考虑用模板仓库或者工具像Husky（不过这是后话了）。还有，hooks脚本得注意兼容性，别假设环境永远一致，比如在Windows和Mac下路径处理可能不同。总之，多测试几遍，别让自动化变成自动捣乱。

用了这些小技巧后，我现在提交代码基本不用操心那些杂事了，专注写业务逻辑就行。大家如果有其他妙招，欢迎交流哈！Git hooks这东西，越用越觉得贴心，简直是小团队的大帮手。