The case against Husky and Git hooks

If you’re a software developer, you’ve probably encountered Git hooks and Husky. They sound like a good deal: predefined checks before each commit catch issues early. I thought the same, until the realities of the tools caught up with how teams actually work.

The trouble with Git hooks and Husky

You know the drill: you’re cranking out code, you’re in the zone, you want to save your progress, and you commit. Then a cascade of linting errors and failed tests slaps you in the face. So much for a smooth flow.

When you’re knee-deep in development it’s normal to commit code at various stages, and it’s not always going to be picture-perfect. Git hooks and Husky aren’t so forgiving; they block commits for the slightest transgression.

The kicker: those rules are easier to dodge than they look. git commit --no-verify skips them entirely. So we end up with a system that’s both painful to deal with and trivial to bypass, a worst-of-both-worlds for code quality.

Branch protection and PR-level checks

The alternative is to move enforcement to where it matters most: branch protection and PR-level checks.

With this approach you can commit code at any stage without being stonewalled by prematurely applied checks. The real scrutiny happens where it counts: when the code is about to enter the main codebase. And there’s no --no-verify escape hatch. Checks at the PR level are applied uniformly, keeping the codebase consistently clean and developer flow uninterrupted.

Final thoughts

I welcomed Git hooks and Husky as gatekeepers of code quality. After seeing them in action, I think we’re better off without them.

Enforce rules at the PR level. Let coding be about innovating and solving problems, not jumping through hoops on the way to a save point.