Why can't client-side Git hooks be trusted to enforce a mandatory engineering policy?

## The claim being tested "We enforce our commit rules with a pre-commit hook" is one of the most common half-truths in interviews. It is worth separating what client hooks genuinely deliver from what they cannot. ## Reason one: hooks are not repository content Git's hook directory is `.git/hooks` — inside the administrative directory, alongside `objects`, `refs`, `config` and `index`. None of that is versioned content. When someone clones, Git transfers objects and refs and then creates a fresh administrative directory from its template, which is where the inert `.sample` files come from. Your carefully written `commit-msg` hook is not in the transfer, was never in a tree, and has no commit history. The consequence is stark: a new hire is not covered, a CI checkout is not covered, a machine reimaged last week is not covered. Even for the people who did install the hook, there is no mechanism keeping their copy current — three developers can be running three different vintages of the rule with nothing reporting the drift. ## Reason two: bypass is a supported feature Git does not treat hooks as a security boundary, and it says so by shipping the escape hatch: - `git commit --no-verify` skips `pre-commit` and `commit-msg`; - `git push --no-verify` skips `pre-push`. That is deliberate. Hooks are the developer's own tooling, and there are legitimate moments — an emergency fix, a hook that is broken, a commit of deliberately unformatted fixture data — where skipping is correct. But the same switch is available to anyone in a hurry, and nothing records that it was used: the resulting commit is an ordinary commit, indistinguishable from one that passed. And because the hook is a plain file the developer owns, `rm .git/hooks/pre-commit` or clearing the executable bit is an equally effective bypass that no one will ever notice. ## Reason three: not every commit goes through the hook Even with a hook installed and never bypassed, coverage has gaps. Commits replayed by `git rebase` do not run `pre-commit`, so content that would have been blocked when first written can land through a rebase. Merge commits go down a different path from ordinary commits. A tool or GUI that constructs commits through Git's lower-level machinery may not trigger hooks at all. "The hook was installed" therefore does not imply "every commit in this branch satisfied it". ## What client hooks are actually good for None of this makes them worthless — it makes them the wrong layer for a guarantee. Their real value is **latency**. A formatting problem caught in 200 ms at commit time costs nothing; the same problem caught minutes later after a full remote verification cycle costs a context switch, and caught in review it costs a second human. Client hooks compress that loop, and a developer who fixes issues before sharing looks more competent, which is its own incentive to keep them installed. ## The layered answer an interviewer wants 1. **Client hooks** — instant, local, advisory. Optimise for speed and clear messages; scope them to what is staged. Accept that they are bypassable and design for that rather than pretending otherwise. 2. **A binding check where changes are received or verified** — running on infrastructure the developer does not control, which is where a rule becomes a guarantee. 3. **Make the two agree.** The failure mode of a layered setup is drift: the local check and the binding one enforce different versions of the rule, so "it passed locally" stops meaning anything. Deriving both from the same configuration is the discipline that keeps the fast layer honest. ## The wrong conclusions Two mistakes bracket this topic. One is treating a hook as a control and reporting to an auditor that a policy is enforced when it is one flag away from being skipped. The other is deleting the local hooks because "they prove nothing" — that throws away the fastest feedback in the whole loop to make a point about rigour. Keep the seatbelt; do not confuse it with a lock.