By ByteBot
Everyone uses git commit --no-verify. Some developers will claim they don’t, but that’s either discipline theater or they haven’t hit a Friday afternoon merge conflict yet. Pre-commit hooks have 14,000 GitHub stars and 11 million weekly downloads. They’re also fundamentally broken. Both things can be true—and the real problem isn’t what the technical critics are arguing.
The Technical Criticism Exists
A recent technical analysis argues pre-commit hooks are fundamentally broken. The core issue: hooks run on your working directory, not your staged changes. Format your code to pass the hook, and the changes aren’t staged—your committed version stays unformatted. During rebases, things get worse. The hook runs against files from an upstream branch you’re rebasing onto, causing failures on code you never wrote. “Our pre-commit hook ran on a branch we were rebasing,” the analysis notes.
The Hacker News discussion (128 points, 104 comments) shows a divided community. Advocates argue hooks catch issues in seconds while CI takes minutes. Critics point to the working tree versus index flaw and suggest pre-push hooks instead. The proposed solution runs checks only when pushing to remote repositories, avoiding local workflow disruptions.
The critics are right about the architecture. But 11 million weekly downloads suggest developers don’t care about technical elegance—they care whether it solves their problem. The architectural flaws matter less than why developers bypass hooks anyway.
The Bypass Culture Is the Real Signal
Git hook failure messages literally suggest the workaround: “add –no-verify to bypass.” That’s not a hidden escape hatch. It’s documented in every tutorial. GeeksforGeeks explains how to skip hooks. Graphite provides guides. Adam Johnson documents the flag. When your tool’s documentation includes bypass instructions, that tells you something.
Security analysts are blunt: “Git pre-commit hook mechanisms are easily bypassed and depend entirely on developer discipline, which doesn’t scale.” The recommended mitigation? “Log and alert when –no-verify is used.” Think about that. Your quality tool now requires audit logs to track when developers circumvent it. If you need to police the police, something has failed.
The workflow looks like this:
git add .
git commit -m "fix: critical bug"
# Hook fails on formatting...
git commit --no-verify -m "fix: critical bug"
# Works. Move on.That’s not an occasional workaround for emergencies. It’s muscle memory. When the bypass becomes the workflow, you’ve built the wrong abstraction. Pre-commit hooks are security theater—visible enforcement that people route around when inconvenient.
This Is a Trust Problem, Not a Technical Problem
What do pre-commit hooks signal to developers? “We can’t trust you to care about code quality.” “We need automation to enforce what should be voluntary.” “Your judgment isn’t sufficient.”
Research on engineering culture is clear: high-trust organizations don’t overprotect or micromanage. They give engineers room to make decisions, own systems, and try new things. That trust pays off in motivation, creativity, and faster iteration. Control leads to compliance. Autonomy leads to engagement.
Spotify achieves 94 percent employee satisfaction through near-complete autonomy, putting community and trust above rigid hierarchies. Engineers hate being micromanaged on the technical side. Pre-commit hooks are technical micromanagement.
The paradox plays out like this:
- Build enforcement tool
- Developers bypass it
- Build audit logs to track bypasses
- Now you’re enforcing the enforcement
- Trust deficit grows
Pre-commit hooks don’t solve a code quality problem. They solve a “we hired developers we don’t trust” problem. Organizations with trusted engineers don’t need forced local enforcement. They have code review. They have CI/CD. They have developers who actually care.
The Numbers Show Continued Investment Despite Problems
The pre-commit framework receives 11.4 million weekly downloads. It has 14,459 GitHub stars, 9,620 dependent packages, and 6,350 dependent repositories. Version 4.5.1 shipped December 16, 2025. Ruff 0.6 integration guides published in 2025 show continued tool investment. Prek, a Rust-based alternative, grew 241 percent to 7.4 million downloads.
If hooks are so broken and bypassed, why are they growing?
Marketing works. “Catches 98 percent of issues before they hit the main branch!” sounds great in process documentation. Hooks work fine until they don’t—rebase edge cases reveal the flaws. The alternative is slower. CI takes minutes where local checks take seconds. Inertia matters. Everyone else uses them, so you use them too.
Popularity doesn’t equal effectiveness. Plenty of bad practices persist because they’re entrenched. The fact that alternatives like prek are surging suggests developers are looking for something better. They just don’t know what yet.
Alternatives Don’t Solve the Root Problem
Pre-push hooks offer better architecture. They run only when pushing to remote repositories, avoiding rebase failures and working directory issues. But they have the same trust problem.
CI-only approaches guarantee enforcement. Nobody can bypass server-side checks. But feedback is slow—minutes instead of seconds—and you waste CI resources on issues local checks could catch.
Hybrid models run lightweight checks locally for convenience, comprehensive checks in CI for enforcement. Post-commit hooks send notifications after commits complete but can’t prevent bad commits from happening.
None of these alternatives address the real question: Why don’t developers care enough about quality to run checks voluntarily?
Should you build tools that force behavior, or hire developers who care and give them tools that help? The debate about pre-commit versus pre-push versus CI misses the point. If you need to force developers to check code quality, you have a people problem or a culture problem, not a tooling problem. Better architecture won’t fix a trust deficit.
The Real Question Nobody Asks
Pre-commit hooks aren’t broken technically. They’re broken philosophically.
When developers systematically bypass your quality tool, you haven’t built the wrong tool. You’ve failed to answer “Why should they care?” Some teams need enforcement because they don’t have alignment on quality standards. Some teams use hooks as training wheels for junior developers. Some teams inherited hooks from past regimes and never questioned whether they’re still needed.
But if your experienced engineers are typing --no-verify by reflex, the problem isn’t hook architecture. The problem is you’ve built a system that treats symptoms instead of causes. Code quality matters when engineers care about their craft, their teammates, and their users. You can’t automate caring.
The hooks will keep growing. Tools like Ruff will integrate deeper. Audit logs will track bypasses. And developers will keep typing --no-verify when hooks get in the way, because enforcement without buy-in is just theater.
Maybe the solution isn’t better hooks. Maybe it’s better hiring, better culture, and better trust.
