The importance of Git hooks

Relevance of Fast Feedback

Generally speaking, feedback plays a crucial role in the learning process. Speed ​​is a form of efficiency improvement. Throughout my career, I've repeatedly experienced that, as an impatient developer, I need to pay particular attention to this.

If there's not only a break in the flow of information between my action and the feedback, but also many minutes passing, frustration is inevitable, and efficiency is low. Worse than lengthy Git hooks is no Git hooks at all. I prefer a balanced approach. Experience shows what works. But first, let's look at how Git hooks help me.

Git Hooks as Quality Assurance

In this article, I want to focus on the pre-push Git hook. This Git hook lets me run actions before pushing code to the repository. It's helpful to implement any quality-enhancing measures beforehand that might cause an error on the build server. The immediate feedback allows me to fix the mistake faster while I'm still mentally present, which would be impossible with an email from the build system 15 minutes later.

However, I shouldn't execute all build steps locally, as this takes too long overall. That's why we built it on a separate system. If more than a minute passes between an action—the git push command—and the feedback, I have to discipline myself to wait for the command to finish and not reflexively check my messenger or email. If I find new content there in the form of messages, I'll deal with them. The distraction is perfect. Perhaps 10 minutes later, I realize, in frustration, that my code hasn't left my machine.

Depending on how tolerant and patient you and your team are, the actions performed in the Git hook can vary in scope and duration. Based on my experience, I recommend aiming for no more than 1 minute. To clarify: The question isn't whether you should use this Git hook. It's mandatory!

What to do in the Git hook?

The above statement applies to all projects whose code is managed with version control, regardless of the programming language or domain. The same is true for the steps I will mention that are performed by the pre-push Git hook:

• Spell check: Depending on the repository size, this check takes less than a second.
• Compiling TypeScript: Checks the type definitions within a few seconds.
• Linting rule compliance: Ensures code formatting is followed within a few seconds.
• Security auditing: Checks whether the NPM packages used have any known vulnerabilities.
• Unit tests: Potentially the most time-consuming and controversial item on the list, because the duration can quickly increase with repository size and poor test quality.

If your team is considering removing unit tests from the pre-push Git hook due to their length, or if team members are getting sidetracked while executing the command, this is a serious warning sign: the tests and their quality have suffered. The resulting technical debt must be a priority for the team. Instead of postponing the testing, the focus should be on improving test performance. Otherwise, fewer and fewer tests will be written in the foreseeable future. This will limit your ability to deliver safely and quickly!

npm run cspell:lint → "cspell:lint": "cspell \"**/*.ts\""
npm run ts → "ts": "tsc --noEmit"
npm run lint → "lint": "eslint src/** --no-ignore --cache --cache-location=node_modules/.cache/eslint"
npm run audit → "audit": "better-npm-audit audit"
npm run test → "test": "vitest run"

My command chain, included via Husky in a Node.js project with the related scripts from the package.json

What I'm not executing in the Git hook

I'm refraining from including test coverage as a percentage metric. As soon as the value falls below an arbitrary threshold, one of two things usually happens: the threshold is lowered, or a frantic attempt is made to write a few tests at random points to raise the value to the minimum. Neither of these improves test or code quality. A strong code review mindset or test-driven development approaches are more effective in this regard.