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/:

repo/
 .githooks/
 pre-commit/
 check-trailing-whitespace.sh
 check-newline-at-eof.sh

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