- Git - Home
- Git - Version Control
- Git - Basic Concepts
- Git - Command Line
- Git - Installation
- Git - First Time Setup
- Git - Basic Commands
- Git - Getting Help
- Git - Tools
- Git - Cheat Sheet
- Git - Terminology
- Git - Life Cycle
- Git - Get a Repository
- Git - Adding New Files
- Git - Recording Changes
- Git - Viewing Commit History
- Git Branching
- Git - Branches in a Nutshell
- Git - Creating a New Branch
- Git - Switching Branches
- Git - Branching and Merging
- Git - Merge Conflicts
- Git - Managing Branches
- Git - Branching Workflows
- Git - Remote Branches
- Git - Tracking Branches
- Git - Rebasing
- Git - Rebase vs. Merge
- Git - Squash Commits
- Git Operations
- Git - Clone Operation
- Git - Tagging Operation
- Git - Aliases Operation
- Git - Commit Operation
- Git - Stash Operation
- Git - Move Operation
- Git - Rename Operation
- Git - Push Operation
- Git - Pull Operation
- Git - Fork Operation
- Git - Patch Operation
- Git - Diff Operation
- Git - Status Operation
- Git - Log Operation
- Git - Head Operation
- Git - Origin Master
- Git Undoing
- Git - Undoing Changes
- Git - Checkout
- Git - Revert
- Git - Reset
- Git - Restore Operation
- Git - Rm
- Git - Switch Operation
- Git - Cherry-pick
- Git - Amend
- Git on the Server
- Git - Local Protocol
- Git - Smart HTTP Protocol
- Git - Dumb HTTP Protocol
- Git - The SSH Protocol
- Git - The Git Protocol
- Git - Getting Git on a Server
- Git - Setting up the Server
- Git - Daemon
- Git - GitWeb
- Git - GitLab
- Git - Third Party Hosted Options
- Distributed Git
- Git - Distributed Workflows
- Git - Contributing to a Project
- Git - Maintaining a Project
- Customizing Git
- Git - Configuration
- Git - Hooks
- Git - Attributes
- Git - Init
- Git - Commit
Customizing Git - Git Hooks
Git Hooks
Git Hooks are scripts that run automatically when specific Git actions are carried out. It allows you to automate tasks and enforce policies, which enhances the workflow.
There are two types of Git hooks: client-side and server-side.
Client-side hooks become active when a transaction is committed or merged.
Network activity such as receiving pushed commits cause server-side hooks to activate.
We can use these highly customized hooks to automate processes like code linting and test runs.
These hooks allow us to maintain uniform practices throughout our development process and optimize workflows.
Server-side hooks are activated when a repository is cloned or when a new branch is created.
Installing a Hook
To install a Git hook, move the script into our Git repository's .git/hooks folder.
Git generates sample hook scripts in this directory when we use git init to initialize a repository.
While example scripts are usually written in Perl or shell script, they can also be written in other languages, such as Python or Ruby.
Rename the scripts (removing the .sample extension) in order to utilize them as examples.
To enable a hook, place an executable script with the correct name and no file extension in the .git/hooks directory.
After the script is configured, it will run automatically during the relevant Git operation.
Client-Side Hooks
Client-side hooks are categorized into three types: committing-workflow hooks, email-workflow scripts, and other miscellaneous scripts.
Committing-Workflow Hooks
We may automate checks and alter commit behaviors with these hooks, which are scripts that execute during the git commit procedure.
pre-commit Hook
It runs prior to typing the commit message.
Used to perform tests, review code style, and make sure documentation is current on changes that are going to be committed.
The commit is terminated if it exits with a state other than zero. It can be bypassed with git commit --no-verify.
prepare-commit-msg Hook
Runs after the default commit message is generated but before the commit message editor opens.
Permits changing the default commit message.
It is helpful for automatically generated messages, such as those pertaining to squashed or merged changes.
Receives options like the commit type, the commit SHA-1 (if it's an altered commit), and the path to the commit message file.
commit-msg Hook
Executes after the writing of the commit message but prior to the commit being completed.
Used to confirm that the project state or commit message satisfies specified requirements.
Git aborts the commit if it quits with a non-zero status. Receives the commit message file's path.
post-commit Hook
Runs upon the completion of the commit process.
Usually utilized for extra tasks or notifications.
Use git log -1 HEAD to see the information of the most recent commit.
There are no parameters required.
Email Workflow Hooks
We can configure three client-side hooks for workflows that use email based patches.
The git am command, which is used to apply fixes received by email, initiates these hooks.
We can ignore these hooks if we don't use git am.
However, these hooks might be helpful if we work with changes made with git format-patch.
applypatch-msg Hook
Runs first and accepts a single parameter, which is the path to a temporary file containing the suggested commit message.
Before finishing the patch application, it is used to verify or edit the commit message.
The patch application is stopped if the script exits with a non-zero status.
pre-applypatch Hook
Runs prior to the commit being created but after the patch has been implemented.
Before committing the changes, we can examine the working tree or perform tests on the modifications.
In the event of any problems encountered and the script leaves with a status other than zero, the git am process will terminate without committing.
post-applypatch Hook
Runs after the commit. It is helpful for notifications or other tasks pertaining to the patch that has been implemented.
Although this script can't stop the patch from being committed, it can be used to do things like inform people that the patch has been applied.
Other Client Hooks
The following hooks are available in the Git client.
pre-rebase Hook
Executes prior to initiating a rebase process.
If it exits with a non-zero state, it can stop the rebase from happening.
In order to preserve shared history, this hook can be used to limit rebases on commits that have previously been pushed.
The logic for this hook is included in Git's default example, although it might need to be modified to meet our particular process.
post-rewrite Hook
Started by commands (not git filter-branch) that change commits, like git commit --amend or git rebase.
It is given a list of the commits that are impacted as well as the command that initiated the rewrite.
This hook is used for updating related systems or sending out notifications, among other things that are handled by the post-checkout and post-merge hooks.
post-checkout Hook
Executes after a successful git checkout.
We can use this hook to set up the working directory and carry out environment-specific actions, such as transferring binary files that Git does not track or automatically creating documentation.
post-merge Hook
Executes after a merge that was successful.
It can be used to recover data that is not managed by Git, like external files or file permissions, making sure that our working directory is set up appropriately after the merging.
pre-push Hook
Runs during a git push, after the updating of remote references but prior to the transfer of objects.
Along with a list of references that need to be changed via stdin, it also receives the remote name and location as arguments.
Before changes are pushed to the remote repository, they can be verified with this hook.
The push is terminated if the hook exits with a non-zero condition.
pre-auto-gc Hook
It is invoked prior to Git using git gc --auto to carry out automatic garbage collection.
It can be used to inform us when waste collection is scheduled or, if it's not an appropriate time, to stop the operation altogether.
Server-Side Hooks
Scripts known as server-side hooks are executed on the Git server to manage different tasks associated with push operations and to enforce policies.
These hooks have the ability to act after a push has been completed or to reject pushes.
pre-receive Hook
When a client pushes modifications to the server, this script is the first to execute.
Through stdin, it receives a list of references (branches or tags).
A non-zero exit status for this hook means that none of the references are accepted.
Use it to implement rules such as restricting access to referees or prohibiting non-fast-forward modifications.
update Hook
This hook functions independently for every pushed branch, similar to the pre-receive hook.
Arguments that are required: the name of the reference, the reference's previous SHA-1, and the new SHA-1 that the client is pushing.
Only that branch update is refused if this hook leaves with a non-zero status; other branch updates may still be accepted.
post-receive Hook
Executes following the conclusion of the push procedure.
Through stdin, it obtains the same reference list as the pre-receive hook.
This hook is used for things like sending emails, updating issue tracking systems, and informing other services (like continuous integration servers).
The client waits for this hook to finish before disconnecting, thus it should be used carefully if it requires lengthy activities even though it cannot interrupt the push process.
Benefits of Using Git Hooks
Following are some of the benefits of using Git hooks:
Automation of tasks − Tasks like testing, formatting, or deploying are repetitive in nature and can be automated using hooks.
Enforcement of standards − Even before code is committed or pushed, ensure enforcement of coding standards and best practices.
Integration with other tools − Lets you integrate with other tools, such as CI/CD pipelines or notification services.
Git hooks are a powerful way to customize your workflow and ensure code quality in your projects.