什么是Git Hooks
Git Hooks本质上是Git仓库中触发特定事件的脚本。当你执行push、commit或merge等操作时，Git会自动运行对应的钩子文件。它的核心价值在于把重复的人工检查变成自动化流程，比如提交前自动格式化代码、拦截不规范的信息、或者在推送前运行测试用例。掌握它后，团队协作的效率会明显提升，也能大幅减少因为低级错误导致的回滚。开发者只需要关注业务逻辑，不用每次手动敲命令核对规范。
Hooks文件的存放位置与类型
每个Git仓库初始化时，都会在根目录下的.git/hooks文件夹里生成一堆示例脚本。这些文件默认以sample结尾，去掉.sample后缀即可启用。需要注意的是，.git目录属于版本控制忽略范围，所以本地写好的Hooks不会自动同步给队友。如果需要团队共用，通常会把钩子脚本放在项目根目录的.husky文件夹或专门的scripts/hooks目录里，并通过配置让工具自动复制过去。常见的钩子分为客户端和服务端两类，最常用的是客户端钩子，包括pre-commit（提交前）、commit-msg（提交信息校验）、pre-push（推送前）以及prepare-commit-msg（修改默认提交信息）。
从零搭建一个Pre-commit钩子
第一步是创建脚本文件。在.git/hooks目录下新建名为pre-commit的文件，注意不要带任何扩展名。第二步写入Shebang声明，告诉系统用什么解释器运行，通常第一行写#!/bin/sh或#!/usr/bin/env bash。第三步编写核心逻辑，可以用Shell命令调用linter或formatter，也可以直接执行Node.js或Python脚本。第四步赋予执行权限，终端输入chmod +x .git/hooks/pre-commit。第五步进行验证，随便修改一个文件并提交，如果脚本设置了退出码不为零，Git就会中断提交并打印错误提示，这样就能把问题拦截在入库之前。
实战案例：集成代码规范检查
假设你的项目使用ESLint和Prettier。可以在pre-commit脚本中加入判断当前暂存区是否包含js或ts文件，如果有就运行lint:fix命令。具体写法可以是if grep -qE "\.(js|ts)$" <<< "$(git diff --cached --name-only)"；then npm run lint:fix；fi。这里用到了Git的diff命令来精准定位变更文件，避免全量扫描拖慢速度。如果检查失败，脚本末尾要加上exit 1，强制终止提交流程。调试时可以在脚本顶部加set -e，遇到报错立即停住，方便快速定位是哪条命令出了问题。跨平台开发的朋友建议统一使用bash语法，或者引入cross-env之类的工具处理路径差异。
避坑指南与维护建议
很多新手第一次写钩子容易踩坑。最常见的是忘记设置执行权限，导致脚本静默跳过。其次是脚本执行时间过长，Git默认有超时保护，耗时超过几秒可能会直接报错中断，这时候需要优化命令，或者把重型任务拆到CI流水线里。另一个细节是钩子里的环境变量和当前工作目录可能不一致，尽量使用相对路径或绝对路径明确指定文件位置。团队维护方面，建议把钩子脚本纳入版本库管理，配合husky或simple-git-hooks这类轻量级工具做分发，既能保证环境一致，又能降低新成员的配置门槛。定期清理废弃的钩子，保持脚本精简，能让仓库保持清爽。
总结
Git Hooks不是银弹，但它是构建规范化工作流的基石。从简单的格式校验到复杂的分支策略拦截，合理搭配客户端钩子和持续集成服务，能让代码质量管控前置。动手写第一个脚本吧，只要跑通一次流程，后续的日常开发就会顺畅许多。遇到问题多查官方文档，结合项目实际调整参数，慢慢就能摸索出一套适合团队的自动化方案。
