Git Hooks – Basic and Advanced – Code Version Master

Git hooks are custom scripts that can be triggered automatically at specific points in the Git workflow. They allow you to automate tasks, enforce policies, or modify the behavior of Git operations.

Hooks are stored in the .git/hooks directory within a Git repository and are typically shell scripts or executables written in any scripting language like Bash, Python, or Ruby.

There are various hooks, each corresponding to a different stage in the Git process. Some standard hooks include:

Pre-commit: This hook is executed before a commit is created. It can be used to check the commit message, enforce coding standards, or run tests. If the hook exits with a non-zero status, the commit will be aborted.
Commit-msg: This hook is triggered after the commit message has been prepared but before the commit is created. It allows you to validate, modify, or enforce rules on the commit message.
Post-commit: This hook runs after a commit has been successfully created. It can be used for notifications, updating external systems, or performing other actions that don’t directly affect the commit itself.

Pre-rebase: This hook is executed before a rebase operation begins. It can be used to ensure that certain conditions are met before allowing the rebase, such as preventing commits with specific characteristics from being rebased.
Pre-push: This hook is called before changes are pushed to a remote repository. It allows you to perform checks, enforce rules, or abort the push if certain conditions are not met.
Post-receive: This hook is executed on the remote repository after a successful push. It can be used to deploy code, send notifications, or update other systems based on the received changes.

Git hooks are essential for automating tasks, ensuring code quality, and enforcing project-specific policies. They provide a powerful mechanism for customizing and extending Git’s default behavior, allowing you to tailor the version control system to your unique requirements.

Table of Contents

An example implementation of pre-commit git hook

Here’s a simple example of a pre-commit hook script that checks for trailing whitespace in the staged files before a commit. This example uses a Bash script, but you can use any scripting language you prefer.

Create a new file named pre-commit in the .git/hooks directory of your Git repository:

touch .git/hooks/pre-commit

Open the pre-commit file with your favorite text editor and add the following script:

#!/bin/bash

# Check for trailing whitespace in the staged files
staged_files=$(git diff --cached --name-only --diff-filter=ACM)

for file in $staged_files; do
  if grep --quiet --extended-regexp '[[:space:]]$' "$file"; then
    echo "Error: Trailing whitespace found in $file. Please remove it and try again."
    exit 1
  fi
done

# If no trailing whitespace is found, allow the commit
exit 0

Save the file and make it executable:

chmod +x .git/hooks/pre-commit

Now, whenever you try to commit changes, the pre-commit hook script will run and check for trailing whitespace in the staged files. If it finds any, it will display an error message and abort the commit, prompting you to fix the issue before trying again.

This is just a simple example, but you can create more complex pre-commit hooks to enforce coding standards, run tests, or perform any other validations that suit your project’s needs.

Management of Git Hooks

Managing hooks in Git refers to the process of creating, configuring, maintaining, and sharing Git hooks across a project or organization.

It ensures that the hooks are correctly implemented, up-to-date, and consistently applied across different development environments.

Some aspects of managing hooks include:

Creating hooks: Writing custom scripts for specific Git operations, such as pre-commit, post-commit, or pre-push, depending on the requirements of your project.
Configuring hooks: Setting up the necessary configurations and parameters for the hooks, ensuring they work as expected in your development environment.

Updating hooks: Periodically reviewing and updating hooks to address any changes in requirements, project policies, or best practices.
Testing hooks: Verifying that hooks work correctly and don’t introduce unexpected behavior, either by manual or automated tests.
Sharing hooks: Distributing hooks across your team or organization, ensuring that all developers use the same hooks and follow the same policies. This can be done by including hooks in the project repository or using a separate repository to store and share hooks.

Documenting hooks: Providing clear documentation about the purpose, functionality, and usage of hooks, ensuring that developers understand their roles and responsibilities when using hooks.
Enforcing hooks: Ensuring that hooks are consistently applied across different development environments and that developers cannot bypass them. This may involve using server-side hooks or integrating hooks with your continuous integration and deployment (CI/CD) pipelines.

Managing hooks is essential to maintaining a consistent and secure development workflow. By effectively managing hooks, you can enforce project policies, automate tasks, and improve the overall quality and security of your codebase.

Less-known advanced git hooks

While the more common Git hooks like pre-commit, post-commit, and pre-push are widely known, several lesser-known hooks can still be useful in specific situations. Here are a few examples:

Pre-applypatch and Post-applypatch: These hooks are executed before and after applying a patch using the “git am” command, respectively. They can be used to enforce specific requirements or perform additional actions when applying patches to your repository.
Pre-auto-gc: This hook is executed automatically by Git before running garbage collection (git gc) when the number of loose objects in the repository exceeds a certain threshold. You can use this hook to perform custom actions or abort the garbage collection process based on specific conditions.

Applypatch-msg: This hook is called when “git am” is used to apply a patch. It allows you to modify or validate the commit message of the patch being applied.
Pre-push: Although more obscure than some others, the pre-push hook is less commonly used. It is triggered before changes are pushed to a remote repository, allowing you to perform checks, enforce rules, or abort the push if certain conditions are unmet.
Update: This server-side hook is executed on the remote repository when a push is received before the changes are accepted. It can be used to enforce policies, perform validations, or reject the push based on specific conditions.

Post-update: This server-side hook is executed on the remote repository after a successful push. It can be used to update other systems, send notifications, or perform other actions based on the received changes.
Pre-receive and Post-receive: These server-side hooks are executed on the remote repository before and after receiving a push, respectively. They can enforce policies, validate changes, or perform custom actions based on the incoming push.

While these hooks may not be as popular as their more well-known counterparts, they can still be valuable in certain scenarios or for addressing specific project requirements. You can customize and extend your Git workflow by leveraging these lesser-known hooks to suit your unique needs.

That’s it.