What is a Git Hook
it is a way to fire off custom scripts when certain important actions occur. Git provides 2 types of hooks, client-side hooks, server-side hooks. Client-side hooks are triggered with the predefined git action, such as commit, push, pull, merge. While server-side hooks run on network operations such as receiving pushed commits, on your Git Server.
How are Git Hooks helpful?
We can script a couple of commands such as linting, static code analysis, auto-format, run unit test, run UI test.
In one of my experiences, I found the team would give intention to minor details and waste a lot of time, code formatting, indentation. I would like to automate such things to make our development faster, easier, and deliver high-quality code. I have installed client-side/local hooks.
Git provides us with 8 local git hooks triggered with those actions:
1. pre-commit ⭐💚
Run once you try to commit, git will execute this script before executing the commit command. It will run over the current snapshot of your code. If your script fails/exits with non-zero, then git will not commit and stop executing git commit command, If you would like to skip it just use — no-verify.
git commit — no-verify
Run after the
pre-commit hook, it runs before the commit message editor is fired up, but after the default message is created.
This hook generally isn’t useful for normal commits; rather, it’s good for commits where the default message is auto-generated, such as templated commit messages, merge commits, squashed commits, and amended commits.
This hook runs once you try to save your commit message/close your commit editor massage, If this script exits non-zero, Git aborts the commit process.
You can use this hook to ensure the commit message matches your team and company standards.
Once the git commit process is done successfully this hook is triggered, I found it useful if you would check if there is an update from the git server in your branch.
This hook runs before you rebase anything and can stop the process by exiting non-zero.
This hook runs once you try to modify a git commit (i.e:
git commit --amend and
git rebase (though not by
git filter-branch)). As an input to this hook, it receives a single argument is which command triggered the rewrite, and it receives a list of rewrites on
This hook runs once the merge process successful. You might use this one to run the integration tests / UI tests, over the current merged code, to ensure nothing broken after the merge.
This hook runs once the checkout process successful. Hence, this hook can be used to set up your working directory properly for your project environment.
If the code in the new checked-out branch need some dependency like run docker container x, or start and pause some local server.
9. pre-push ⭐💚
This hook runs once you try to push, during the git execute git push command, this script executed after the remote refs have been updated but before any objects have been transferred, if this hook script fails, it exits with non-zero, and stop the push process.
I use this one to run a Static code analyzer, if my code has some problems or contradicts the company standards, it tells me what are the problems, and I’m on the safe side to push a clean code 😉.
This hook runs just before git garbage collection takes place, and can be used to notify you that
garbage collection is happening.
This server hook runs once receive a push from a client, It takes a list of references that are being pushed from stdin; if it exits non-zero, none of them are accepted. You can use this hook to do things like making sure none of the updated references are non-fast-forwards, or to do access control for all the refs and files they’re modifying with the push.
Some common use cases include:
- Rejecting changes that involve an upstream rebase
- Preventing non-fast-forward merges
- Checking that the user has the correct permissions to make the intended changes (mostly used for centralized Git workflows)
This hook runs after
pre-receive, and it works much the same way. It’s still called before anything is actually updated, but it’s called separately for each ref that was pushed. That means if the user tries to push 4 branches,
update is executed 4 times. Unlike
pre-receive, this hook doesn’t need to read from standard input. Instead, it accepts the following 3 arguments:
- The name of the ref being updated
- The old object name stored in the ref
- The new object name stored in the ref
This is the same information passed to
pre-receive, but since
update is invoked separately for each ref, you can reject some refs while allowing others.
This hook runs after a successful push operation, making it a good place to perform notifications. For many workflows, this is a better place to trigger notifications than
post-commit because the changes are available on a public server instead of residing only on the user’s local machine. Emailing other developers and triggering a continuous integration system are common use cases for
The script takes no parameters but is sent the same information as
pre-receive via standard input.