Hooked on Git

April 11, 2016

Hooked on Git

At some point in your career as a software developer, you’ve probably typed in a Git commit message similar to the following:

  • Fix style checker warnings
  • Fix style checker warnings AGAIN...
  • Fix broken test
  • whitespace

Commits like these tend to happen when you forget to run your code linters or test suite before pushing code to the remote repository. A continuous integration server never forgets to run these and posts angry red messages to your Slack channels when the build fails.

Fortunately, Git has a hooks feature which can run checks for you automatically at certain points in your workflow such as:

  • Before you commit (pre-commit)
  • After you write a commit message (commit-msg)
  • Before you push to a remote (pre-push)

There are several more events that Git has hooks for, but I’ve found that these three are the most useful to me.

pre-commit Hooks

I commonly use this hook to catch whitespace related issues, namely ensuring that the files getting committed have a newline at the end of the file and contain no trailing whitespace. When you run git commit, git will run the pre-commit hooks. If the hooks fail, Git will not allow you to enter a message and commit the staged files. This hook is also very useful for running linter tools, such as pep8, checkstyle, or swiftlint before committing files, which can prevent style fixup commits later on.

commit-msg Hooks

This hook is useful for making sure that commit messages are formatted correctly. Commit message formatting is a large topic by itself, so I won’t get into that too much here. Personally, I’ve based my commit message style on the rules from this blog post and wrote a python script which checks most of these rules.

pre-push Hooks

It’s a good idea to check that your test suite passes before pushing code so that you don’t have to add “Fixed a test” commits or modify history that has been made public. I also use this hook to ensure that I don’t accidentally push any WIP (work in progress) commits, which make the history confusing and cluttered.

Making Git Hooks Easy

Vanilla Git hooks are not super intuitive and can be rather limited. You can only have one script for each type of hook which must be named after the hook. Hooks live in the .git/hooks/ folder which is not tracked by Git. If you want to track changes to your hooks, you need to symlink the scripts in your repository to the .git/hooks/ directory.

These limitations frustrated me, so I wrote a tool to make hooks easier to deal with. It is a single shell script that lives in your repository. After you install it, any number of hooks you want to run can be placed in the .githooks/ directory (which you can track in Git). For example, with the pre-commit hooks I described earlier, both scripts will be run before a commit if they are placed in .githooks/pre-commit/:


Please check out the examples for more useful Git hooks and send me your own if you have more ideas!

Josh Friend
Josh Friend
Development Practice Co-Lead

Stay in the loop with our latest content!

Select the topics you’re interested to receive our new relevant content in your inbox. Don’t worry, we won’t spam you.

Time Check

Time Check

June 6, 2019

Read Karl's blog post about an interesting development challenge related to time.

Read more
Using View Model Protocols to manage complex SwiftUI Views

Using View Model Protocols to manage complex SwiftUI Views

March 11, 2021

Managing complex screens or views that depend on asynchronous services or the need to pull in state from across your app can be tricky to get right. The most common way to address this in SwiftUI is by abstracting that logic into a dedicated view model for that piece of UI.

Read more
Creating an Emotionally Safe Workplace: We All Play a Role

Creating an Emotionally Safe Workplace: We All Play a Role

March 4, 2021

Read more
View more articles