No. Client-side Git hooks live on each developer's machine, are not copied when a repository is cloned, and can be bypassed with a commit flag. They give quick feedback. Enforcement has to happen on the server or in CI, where nobody can skip it.
The myth
"We added a pre-commit hook that checks for security problems, so nothing risky gets committed."
It sounds reasonable, and the hook is useful. The belief that it guarantees anything is the problem.
The facts
The Pro Git book describes two groups of hooks: client-side and server-side. Client-side hooks fire on operations like committing and merging, while server-side hooks run on network operations such as receiving pushed commits. It then states that client-side hooks are not copied when you clone a repository, and that if you intend to enforce a policy, you will probably want to do it on the server side.
The same book notes that a failing pre-commit hook aborts the commit, but you can bypass it with the no-verify option.
So three things are true at once:
- A new clone has no hooks until someone installs them.
- A developer who has them can skip them for any commit.
- Anything committed locally still reaches the shared repository unless something there stops it.
What this means in practice
| Claim | Reality |
|---|---|
| "Everyone runs our hook" | Only people who installed it, and only until they skip it |
| "The hook blocks bad commits" | It blocks them on that machine, unless bypassed |
| "CI is redundant with the hook" | CI is the enforcement, the hook is a convenience |
| "A hook failure is a security event" | It is a hint, not an audit record |
A better split
- Hook: fast, simple checks that save a round trip, such as formatting and obvious mistakes.
- Pull request check: the real scan, required before merge.
- Server-side protection: branch rules that prevent direct pushes to the main branch and require the check.
If your policy matters, it should exist in the second and third places. The hook is a bonus.
Do not punish bypasses
If people use the bypass flag often, the hook is probably too slow or too noisy. Fix the hook before blaming the people. A hook that is quick and accurate rarely gets skipped.
Steps to fix an over-trusted hook
- List what your hook checks today.
- For each check, ask whether CI also runs it. If not, add it.
- Mark the CI job as required in branch protection.
- Keep only the fast subset in the hook.
- Document that hooks are advisory, so nobody assumes more.
Where Safeguard fits
Safeguard's policies and gates run at the pull request, which is a stage the author cannot skip locally. The CLI and the VS Code and JetBrains extensions give the fast local feedback. Try a scan at https://gold.safeguard.sh/scan.
Quick check
Can a server-side hook enforce policy?
Yes, server-side hooks run when commits are pushed to the server. Many teams get the same effect with required checks and branch protection on their hosting platform.
Are pre-commit hooks pointless then?
No. They save time by catching simple issues early. They just should not be your only control.
Sources
Last reviewed: 19 October 2026.
