-
- Joined
- Mar 22, 2026
-
- Messages
- 355
-
- Reaction score
- 0
-
- Points
- 0
Git hooks are powerful, customizable scripts that Git executes before or after events like committing, pushing, or receiving commits. They're essentially a built-in mechanism for automating tasks, enforcing policies, and integrating with external systems directly within your version control workflow. Understanding and leveraging them can significantly improve code quality, consistency, and team efficiency.
What are Git Hooks?
At their core, Git hooks are executable scripts (often shell scripts, Python, Ruby, etc.) stored in the
Types of Hooks
Git hooks are broadly categorized into two types:
1. Client-Side Hooks: These run on your local machine and affect only your repository. They are typically used for local development tasks like enforcing commit message formats, running tests, or linting code before a commit.
*
*
*
*
*
*
2. Server-Side Hooks: These run on the remote Git server and enforce policies across the entire team. They are crucial for maintaining repository integrity and integrating with CI/CD pipelines.
*
*
*
How to Use Git Hooks
Every Git repository comes with example hook scripts in the
Let's walk through an example: a
1. Navigate to your hooks directory:
2. Create or edit the
3. Add your script content:
Open
Now, try to commit a JavaScript file that violates your ESLint rules. The commit will be blocked, and you'll see the ESLint errors. If you run
Practical Applications
Managing Hooks in a Team
The biggest challenge with Git hooks is that they are local to each repository and not version-controlled themselves (the
Git hooks are an indispensable tool for maintaining project health and streamlining development workflows. By automating mundane tasks and enforcing critical policies, you can significantly reduce errors and free up developers to focus on building features. Experiment with them to find what works best for your projects and team!
What are Git Hooks?
At their core, Git hooks are executable scripts (often shell scripts, Python, Ruby, etc.) stored in the
.git/hooks directory of your repository. When a specific Git event occurs (e.g., git commit), Git checks if a corresponding hook script exists and, if it does, executes it. If a "pre-" hook script exits with a non-zero status, the Git operation it's guarding is aborted. This allows for powerful validation and control.Types of Hooks
Git hooks are broadly categorized into two types:
1. Client-Side Hooks: These run on your local machine and affect only your repository. They are typically used for local development tasks like enforcing commit message formats, running tests, or linting code before a commit.
*
pre-commit: Runs before a commit is created. Ideal for linting, running unit tests, or checking for common issues. If this script exits with a non-zero status, the commit is aborted.*
prepare-commit-msg: Runs after the pre-commit hook, but before the commit message editor is launched. Useful for auto-generating parts of the commit message.*
commit-msg: Runs after the user has entered a commit message. Great for validating the commit message format against team standards (e.g., requiring a Jira ticket ID).*
post-commit: Runs after a commit is successfully created. Can be used for notification, updating a changelog, or triggering a CI build.*
pre-rebase: Runs before git rebase starts. Prevents rebasing if certain conditions aren't met.*
post-merge: Runs after a successful git merge command. Useful for restoring permissions, regenerating configuration files, or notifying about merge completion.2. Server-Side Hooks: These run on the remote Git server and enforce policies across the entire team. They are crucial for maintaining repository integrity and integrating with CI/CD pipelines.
*
pre-receive: Runs when a push is received but before any references are updated. Can be used to reject pushes that don't conform to project rules (e.g., pushing directly to main).*
update: Similar to pre-receive but runs once for each ref being updated. Allows for more granular control over which branches can be updated and by whom.*
post-receive: Runs after a push has successfully updated references. Commonly used to trigger CI/CD builds, update external issue trackers, or send notifications.How to Use Git Hooks
Every Git repository comes with example hook scripts in the
.git/hooks directory. These examples are named with a .sample extension (e.g., pre-commit.sample). To enable a hook, you simply remove the .sample extension and make the script executable.Let's walk through an example: a
pre-commit hook to ensure all staged JavaScript files pass a linter before committing.1. Navigate to your hooks directory:
Code:
bash
cd your-repo/.git/hooks2. Create or edit the
pre-commit file:
Code:
bash
touch pre-commit
chmod +x pre-commit3. Add your script content:
Open
pre-commit in your favorite editor and add the following (assuming you have eslint installed and configured):
Code:
bash
#!/bin/sh
# Stash uncommitted changes to avoid linting files not part of the commit
git stash -q --keep-index
# Get a list of staged JavaScript files
JS_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep '\.js$')
if [ -n "$JS_FILES" ]; then
echo "Running ESLint on staged JavaScript files..."
# Run ESLint on the staged files
# The --no-error-on-unmatched-pattern is useful if no JS files are staged
./node_modules/.bin/eslint --fix $JS_FILES --no-error-on-unmatched-pattern
LINT_RESULT=$?
# Add any fixes by ESLint back to the stage
git add $JS_FILES
if [ $LINT_RESULT -ne 0 ]; then
echo "ESLint failed. Commit aborted."
git stash pop -q # Restore stashed changes
exit 1 # Abort the commit
else
echo "ESLint passed."
fi
fi
git stash pop -q # Restore stashed changes
exit 0 # Allow the commit to proceedNow, try to commit a JavaScript file that violates your ESLint rules. The commit will be blocked, and you'll see the ESLint errors. If you run
eslint --fix, the changes will be automatically staged and the commit can proceed.Practical Applications
- Code Quality: Enforce linting, formatting (Prettier, Black), and basic unit tests (
pre-commit). - Commit Message Standards: Ensure every commit message follows a specific pattern (e.g.,
TYPE(scope): Subject Line) usingcommit-msg. - Preventing Bad Pushes: Block pushes to
maindirectly or pushes with large files (pre-receive,update). - CI/CD Integration: Trigger a Jenkins, GitHub Actions, or GitLab CI build after a successful push (
post-receive). - Deployment Automation: Automatically deploy to a staging server after a push to a specific branch (
post-receive).
Managing Hooks in a Team
The biggest challenge with Git hooks is that they are local to each repository and not version-controlled themselves (the
.git/hooks directory is excluded from Git). To share hooks across a team:- Manual Copying: Simple but error-prone.
- Symbolic Links: Create a
hooksdirectory in your project's root, version control the scripts there, and then symlink.git/hooksto this directory. Requires setup for each developer. - Dedicated Tools: Tools like
Husky(for JavaScript/Node.js projects),pre-commit(for Python), orgithooks(Go) simplify hook management by allowing you to define hooks in yourpackage.jsonor a configuration file, making them easy to install and share.
Git hooks are an indispensable tool for maintaining project health and streamlining development workflows. By automating mundane tasks and enforcing critical policies, you can significantly reduce errors and free up developers to focus on building features. Experiment with them to find what works best for your projects and team!