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.
pre-pushhook would be more appropriate than the
pre-commithook, 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.
--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?
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.