Pre-commit: Don’t git hooked!

Git hooks are a feature of git that enable custom scripts to be triggered on certain events during the execution of a git command, such as pre-commit and pre-push. It’s common practice for teams to use git hooks to run quality checks to ensure they are run by all developers every time. While this is a good sign that a team cares about quality and repeatability, I observe that this practice has some major downsides. In this article, I’ll explore why, and what you might do instead.

​In order to maintain a stable build, teams practicing Continuous Integration gain confidence by running quality checks before committing or pushing to trunk (master). Examples include code formatting, linting, and unit testing.
 
While the checks are valuable, they also take time to run. As a matter of practicality, we strike a balance between confidence and speed. This leads us to select the checks that provide the greatest confidence in the shortest time. In other words, we trade confidence for speed. The build serves as a safety net, and we stand ready to fix the build when it breaks.

Remembering to run the checks can take some discipline so it’s no wonder that git hooks are used as guardrails to ensure it.

But what if you are disciplined? What if you literally just ran the checks out of discipline, only to be forced to wait for them to run again on the pre-commit hook? What if you’re practising test-driven development (TDD) and have developed a habit of small and frequent commits? Unless the checks are really fast, that kind of wait time is enough to be distracted, break the developer experience, and impede productivity.
 
I was recently pairing with a colleague and we were ready to commit about once every 10 minutes. We were running the quality checks regularly out of habit, and each run took about about 2½ minutes. That’s a long time! Upon success, we’d commit and push. The pre-commit hook would re-run the very same checks we literally just ran! These may not sound like big numbers, but consider that for every 10 minutes of development, at least 5 additional minutes were spent running checks. That’s 50% of the development time! On a more positive note, the wait time enabled us to get to know each other a little better, although the checks had well and truly completed by the time we refocused our attention.
  Git hooks used in this way are a sign of a team that cares about quality. This is a good thing. However it’s also important to note that when developers feel impeded, they will find a workaround. When developers start delaying commits, increasing the size of commits, or batching commits to defer pushing their changes, we are losing ground. Continuous Integration is about minimising the time any change is isolated from any other change. The pre-commit experience needs to be fast and frictionless to encourage the behaviours needed to achieve Continuous Integration.



You may be wondering whether the pre-push hook would be more appropriate than the pre-commit hook, with the thought being that we could batch commits and defer running the checks until we’re ready to push. My question to you would be, why are you not pushing every commit? Doesn’t the thought of making a series of potentially broken commits until “the last one” make you feel slightly uncomfortable? How long are you actually holding onto those changes? Are you actually practising Continuous Integration by pushing your changes to trunk many times per day? Good commits are small, specific, and tested. Test-driven development inherently yields commits of this quality.
 
Of course you could just bypass the hooks altogether with --no-verify. Does the thought of this make you feel guilty? Are you scared of breaking the build? Does your team believe the build should always be green? Does your team have a culture of shaming broken builds? If this sounds like your team, take a step back and ask why. Is it possible that being so preventative is actually encouraging behaviours that impede productivity? Have you got the balance right?
 
What about the so-called junior developers in the team? You know—the ones who aren’t so disciplined? Aren’t hooks a good way to ensure they’ve run the checks? Maybe. But at the end of the day, we want developers to run the checks because they’ve come to understand and value them, not blindly because some guardrail enforced them. Ironically, the discipline of maintaining a stable build is gained through the experience of breaking the build.

While git hooks are a compelling guardrail to help enforce quality, like any guardrail, they also come with some downsides including slowing down well-disciplined developers, and withholding opportunities for less-disciplined developers to gain that discipline.

Consider the following ideas to improve discipline and reduce reliance on git hooks as guardrails in your team:

• Make the quality checks really fast. Like 10 seconds fast! The faster they are, the more likely they are to be run frequently, or ideally, continuously.
   
• Practise test-driven development. The small increments driven by the red-green-refactor cycle demand fast-feedback. The pain felt experiencing slow-feedback during TDD should create incentive to make the quality checks faster.
   
• Practise continuous integration with trunk-based development. The small increments driven by frequent (many times per day) and stable commits to trunk demand fast-feedback.
   
• Commit frequently and push every commit. Small increments demand fast-feedback. The “test && commit || revert” approach helps to encourage this kind of workflow.
   
• Practise pair programming. Pairing is a great way to learn practices like TDD and helps improve discipline by encouraging good behaviour between each other.
   
• Be very selective about what to include in the quality checks to keep them fast. This might mean choosing not to run the end-to-end tests for example. It’s great to have the ability to run the entire pipeline locally, but avoid enforcing it to be run during pre-commit.
   
• Consider that tech choices including languages and tools often have a direct impact on the speed of the checks. For all their benefits, compiled languages (e.g. C#, Java, Scala), transpilers (e.g. TypeScript), and containers (Docker), for example, come at the cost of taking longer to run. Be critical about balancing the pros and cons of these choices.
   
• Don’t shame broken builds. See a broken build as an opportunity to build discipline by allowing the team to feel the impact and learn from the experience.
   
• Remember that the build is your safety net. Keeping the build stable does not mean preventing the build from ever breaking, but stand ready to fix the build when it does break.​

Disciplined teams can avoid the overhead of guardrails when team members understand and come to value good practices. Rather than focusing effort into guardrails to prevent developers doing the “wrong thing”, focus on building discipline so that developers will learn to do the “right thing”.