September 25, 2019

Automating work with Git hooks

Git hooks are scripts that are executed either on you local machine or server-side when certain events happen. They are files stored under .git/hooks.

Git hooks have many use-cases and are only limited to ones imagination. Basically they help you with your workflow and automate processes.


The different types of git hooks and they are useful for different things. Here are some of them.

  • Pre-commit – Triggered before committing your changes
  • Post-commit – Triggered after changes has been committed
  • Pre-push – Triggered right before making a push to a repository
  • Post-merge – Triggered after a merge has been completed
  • Post-receive – Triggered on the server after having received a push from a client


You could use a pre-commit hook to check if your code follows your projects lint-file. (The pre-commit.sample* file has a default method of checking if there are any trailing white-spaces).

You could use a prepare-commit-msg hook to write a custom default git message. This could be practical if you want everyone on your team to follow a specific outline model, for example, writing which user story a certain commit is related to.

If you want to check for spelling errors on your commit message you can do so in the post-commit hook and use Aspell.

Maybe you would like to deploy your production code when there has been a new push to master. Then post-receive could help you with that.

In a new git repository there are a bunch of sample hooks under .git/hooks that have the extension .sample*. To use the sample hook, simply remove the .sample extension from the file name. For example, if you want to show an error when there are trailing whitespaces simple rename pre-commit.sample* -> pre-commit*. Now Git will warn you every time you try to commit trailing whitespaces!

Setting them up

There are different ways of setting up the git hooks, depending on which version of git you are using. To get your current Git version run this in the terminal

git --version

Since you won’t be able to push any changes inside the .git directory you probably want to store your hooks in another folder. From now on I will assume that you have your hooks in a folder called ‘.githooks’.

Version 2.9 or later

Git has a nice configuration option which allows you to specify where you have placed your git hooks.

git config core.hooksPath .githooks

Earlier than 2.9

To get the hooks to work, they need to be copied into the .git/hooks folder, or rather, create a link between the files in .githooks and .git/hooks.

If you simply copy the files, they won’t automatically update when there are updates to them in the future.

To create a link run the statement below.

ln -sf ../../.githooks/pre-commit .git/hooks/pre-commit

The above statement will create a link for the pre-commit hook. You will have to have one statement for each hook. But if you instead just want to copy every hook just run the following instead.

find .githooks -type f -exec ln -sf ../../{} .git/hooks/ \;

Sharing your Git hooks in the team

Sharing the hooks require you to include a setup script somewhere. This is something that could typically be done in a Makefile. If you are using npm it could be defined in the build script inside package.json.


There exists several git hook managers out there. So if you don’t feel like setting up everything from scratch there are alternatives. Here are two examples of managers that I like.

Finally, there is much more functionality with Git hooks. To learn more, here are some useful links.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *