钩子拦下提交的证据
怎么确认 pre-commit 钩子真把一次坏提交拦下了？【0】。
从现象认拦截原因
把四种现象和「为什么没拦住 / 拦住了」配对，打印四个字母：
装上 pre-commit 钩子
场景：~/proj 里已备好一个会跑 CI 的钩子脚本 ~/proj/hook.sh，但还没装到 git 的钩子位置上。 任务：按说明把它装成 pre-commit 钩子（放到位、给执行权限），让以后每次提交都先跑它。装好运行 ~/chec
哪次提交被拦下
场景：~/proj/hook.log 记了几次提交尝试，其中一次被钩子拦下。对照表列了八个提交号。 任务：从日志里看出哪次提交被拦下，到对照表里查它对应的标记。 范围：只在 ~/ 下你自己的仓库里操作；答案是运行后拿到的一段标记。 提交：把
拦下了几次坏提交
场景：~/proj/hook.log 记了一串提交尝试，有几次被拦下。对照表列了八个数。 任务：数出一共拦下几次（标 BLOCKED 的行数），到对照表里查那个数对应的标记。 范围：只在 ~/ 下你自己的仓库里操作；答案是运行后拿到的一段标
上一次全绿是哪个提交
场景：~/proj/hook.log 按时间记了每次提交是 PASS 还是 BLOCKED。对照表列了八个提交号。 任务：找出最后一次通过（PASS）的提交号，到对照表里查它对应的标记。 范围：只在 ~/ 下你自己的仓库里操作；答案是运行后
下一个版本号是几
场景：~/proj/说明.txt 写了当前版本号和这次改动类型（破坏/功能/修复）。对照表列了八个版本号。 任务：按 SemVer 算出下一个版本号，到对照表里查它对应的标记。 范围：只在 ~/ 下你自己的仓库里操作；答案是运行后拿到的一段
修好钩子让它真拦得住
场景：~/proj 的 pre-commit 钩子有 bug——检查挂了它仍以 0 退出，坏提交照样进。 任务：把钩子改对：检查不过时以非零退出，真把坏提交拦下。修好运行 ~/check（它试提交一个坏改动、核对被拦下）。 范围：只在 ~/
让钩子能被执行
场景：~/proj 的 pre-commit 钩子内容是对的，但没有执行权限，git 根本不跑它，坏提交畅通无阻。 任务：给钩子加上执行权限，让它每次提交前真的跑起来。修好运行 ~/check（它试提交坏改动、核对被拦下）。 范围：只在 ~
交付:写个拦坏提交的钩子
场景：~/proj 里有一条 CI 脚本，说明写了怎么调。 任务：写一个 pre-commit 钩子并装到位：每次提交前跑那条 CI，全绿才放行、有挂就以非零退出拦下。写好运行 ~/check（它分别试一个好提交和一个坏提交）。 范围：只在