Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. Git hooks are a built-in feature - no need to download anything. Git hooks are run locally.
These hook scripts are only limited by a developer's imagination. Some example hook scripts include:
pre-commit: Check the commit message for spelling errors.
pre-receive: Enforce project coding standards.
post-commit: Email/SMS team members of a new commit.
post-receive: Push the code to production.
Every Git repository has a
.git/hooks folder with a script for each hook you can bind to. You're free to change or update these scripts as necessary, and Git will execute them when those events occur.
Here's a full list of hooks you can attach scripts to:
Hooks are scripts that help you enforce policies on your repository by triggering scripts at certain events that enforce policies such as 'The commit message must be longer than 20 characters' or 'The test suite must be run before a commit and if it fails, reject the commit'.
Hooks are available in every VCS I have used before. They are also available in Visual Sourcesafe which is not a VCS.
In Git the hook scripts can be implemented using any language but Shell, Ruby, Perl and Python scripts are the most common as far as I know.
The language of the script is determined by the shebang notation as it is usually in Linux based software. Note that this also applies to Windows because Git for Windows runs under MSYS.
If you supply the --no-verify argument to the git command then the command will still be executed even if one (or more) of the hooks failed (i.e. returned a non-zero status code). Please do this only if you know what you are doing.
These hooks reside under the .git/hooks/ directory of your repository.
For a quick reference you can open your favorite shell and type:
git hooks --help
Seriously now, no one wants to be the guy/girl who has to bring coffee & doughnuts at his/her expense for tomorrow’s standup meeting because he broke the build so we want to make sure our codebase does exactly what it should. If it happens to you too many times you might end up being broke :)
We want the test suite to run automatically every time we change something. It's one of the reasons we have a test suite, so we know we're on the right path and things aren't broken.
We also want to make sure that our test coverage is high enough, because untested code won't break the build but it will surely break your production environment.
Allow me to paraphrase a line from the movie “Training Day” (It’s a great movie by the way)
I don’t know about you guys but I wanna’ go home. I implement these hooks for every project I work on.
Apart from testing, we want to make sure that our codebase fits our style guidelines so we need to run a lint tool.
We also want to make sure that the docs can be generated and that every public module, class & method is documented.
Remember that time where you spent a day figuring out what changed in a specific commit that caused major downtime because the commit message was “Fixed this bug” for a commit that added new 20 files and modified 90 other files? If you don’t want to repeat that experience than we have to make sure that we know exactly what changed in each commit.