Git Hooks
Git Hooks Overview
Just like other version control systems, Git has its way to deliver customized scripts whenever some important activity occurs. The hooks act just like the triggers or catalysts that get activated whenever an important event is invoked. However, hooks are mostly used whenever you want to customize Git's internal behavior in a way you want. It automatically fires-off actions considering key points in the life cycle of development.
Nature of Hooks
Hooks in Git are the simple scripts that are executed whenever a special event occurs in your repository. This nature makes it easier for the developers to install the system and configure it.
Unlike the other version control systems, Git Hooks consist of two groups namely: client-side and server-side. Client-side hooks are invoked whenever you try to merge or commit the files in the repository while server-side hooks occur when you run network operations like pushing commits, pulling, etc. You can use the hooks for all sorts of reasons.
Installing a Hook
By default, hooks in Git are stored in sub-directories. In the majority of projects, hooks are stored in the directory like the format .git/hooks. While initializing the Git repository with the init command, Git fires-off the sample scripts. Some of which are used by self and some are used to input values in each script. All these sample scripts are written in bash scripts with some Perl-coded automation.
You can also write the scripts in any language. If you think of using the hooks in the bundle and create sample scripts, you will have to rename them sample scripts ending with the extension .sample.
Therefore, to use a hook script, you will need to put a file in the sub-directory in Git and name it with proper convention without any extension. Doing so will cover the hook filenames appropriately and in the forward point, it will be easier to call them.
Scope of Hooks
Hooks in general, stay local in any repository. They cannot be copied to new repositories whenever you try to clone them. This limitation is quite absurd because it can be easily altered by any individual who has access to the repository.
Another scope of limitation is that while configuring hooks amongst a team of developers, you need to make sure hooks stay updated amongst the other team members. Also, you cannot force other members to create commits every time in a different way. They may not do so.
Lastly, the hooks are difficult to manage and seem pretty complex because the directory .git/hooks are not under version control and are not cloned and integrated with the rest of the project's files. As suggested by most developers, an efficient solution is to store your hooks under the project's leading directory primarily. It will let you configure and modify them just like version-controlled files with other files present in your project. To do this, you create a symlink in the .git/hooks directory, or you can copy and paste them whenever you update your hooks.
Types of Hooks
Server-side hooks
Server-side hooks, as already discussed, behave as local ones except for the fact that their residence lies in the central or a public repository delivered and managed by the developer. When attached to a central or public repository, Server-side hooks can efficiently serve to enforce and reject specific commits in their policy.
There are although various server-side hooks but we’ll be discussing about the main types. They are:
- Pre-receive: It gets executed whenever you try to push your commit. It usually resides in the destination repository and not in your local originating repository.
- Update: It executes in the three-way method i.e. first the reference name is updated, then the old reference name is updated and then the new reference name is updated.
- Post-receive: It executes after you push your commits thereby enforcing the notification to appear post committing with no parameters in hand. It simply sends the information via pre-receive via standard input.
Client-side hooks
Client-side hooks or local hooks have the limitation of influencing only the repository in which they reside. As already discussed, local hooks are only able to alter their hooks so they can't be used to invoke the commit policies a developer might have established. These guidelines are needed to have adhered developers who use them.
In general, local hooks comprise 6 types. They are:
- Pre-Commit
- prepare-commit-msg
- commit-msg
- post-commit
- post-checkout
- pre-rebase
The first 4 types are primarily used to plug-in the complete life cycle of the project undertaken.
The remaining 2 types are used for safety checks and other operations when integrated with git checkout and git rebase command respectively.