Git Hooks & Automation for QA

A hook is a script Git runs at a specific moment — before a commit is written, before a push leaves your machine. It is the cheapest quality gate in existence, and it runs before CI has even heard about your branch.

Why This Module Matters

Every team has a class of defect that gets caught twenty minutes too late: a formatting violation, a failing unit test, a console.log left in, a debugging .only that silently disabled the rest of the test suite.

CI catches all of them. CI also takes fifteen minutes, occupies a runner, and tells you in a notification you read while doing something else. A pre-commit hook catches the same things in two seconds, on your machine, before the commit exists.

For a QA engineer this is one of the highest-leverage things you can bring to a team. A pre-push hook that refuses to push when the smoke tests fail costs a morning to set up and removes an entire category of broken builds — and it is a change QA can propose and own without needing anyone's pipeline permissions.

The module is equally clear about the limits. Hooks are local, they are not committed by default, and they can be bypassed with --no-verify. That makes them a fast helpful assistant, never the authority. CI remains the gate that actually decides.

What You'll Learn

• Where hooks live (.git/hooks/), how Git decides to run one, and why the executable bit matters
• The hooks worth knowing: pre-commit, commit-msg, pre-push
• Writing a pre-commit hook that runs a linter and blocks the commit on a non-zero exit
• Writing a pre-push hook that runs the fast test suite, and keeping it fast enough that nobody disables it
• --no-verify, and being honest about what it means for your gate
• Sharing hooks across a team with core.hooksPath or a tool like Husky or pre-commit

Pro Tip

Keep a pre-commit hook under about five seconds. Past that, people start typing --no-verify out of habit, and a bypassed hook protects nothing at all. Put the slow checks in pre-push, and the truly slow ones in CI.