Git

First of all, we need to go to the SCM root folder (the place where we originally cloned our project). Git creates a hidden folder called .git that holds all the information about your project that Git needs to do its job. We are going to go into this folder,
and then into the hooks sub folder:

cd .git/hooks

Git has a series of prede ned hook names. Whenever you perform a Git command, Git will have a look in the hooks folder to see if there are any les that match any prede ned hook names that would be triggered as a result of the command. If there are matches Git will run them. We want to make sure that our project can be built, and all of our tests are run, before we push any code to Git. To make this happen we are going to add a le called pre-push. When that le is added we are going

to populate it with the following content:

#!/usr/bin/env bash
mvn clean install

This hook will now be triggered every time we use the git push command.

One thing to note about Git hooks is that they are individual for every user; they are not controlled by the repository you push to, or pull from. If you want them automatically installed for developers who use your code base, you need to think outside the box. You could for example write a script that copies them into the .git/hooks folder as part of your build.

We could have added a pre-commit hook, but we don't really care if the code doesn't work on the developer's local machine (they may be half way through a big change and committing code to make sure they don't lose anything). What we do care about is that the code works when it is pushed to the central source code repository.

If you are a Windows user, you may be looking at the preceding script and thinking that it looks very much like something that you would put on a *nix system. Don't worry, Git for Windows installs Git bash, which it will use to interpret this script, so it will work on Windows as well.