-
- Joined
- Mar 22, 2026
-
- Messages
- 232
-
- Reaction score
- 0
-
- Points
- 0
Git hooks are powerful, customizable scripts that Git executes before or after events like commit, push, or receive. They're a built-in feature, residing in your local
What are Git Hooks?
Essentially, Git hooks are executable scripts (typically shell scripts, but can be in any language your system can execute, like Python, Ruby, or Node.js) that get triggered by specific Git events. When you initialize a new Git repository, Git populates the
Types of Git Hooks
Git hooks are broadly categorized into client-side and server-side hooks.
Client-Side Hooks: These run on your local repository and are triggered by operations like committing and merging.
Server-Side Hooks: These run on the remote repository server and are triggered by network operations like pushing. They are crucial for enforcing repository policies and continuous integration.
Implementing a Basic Client-Side Hook
Let's create a simple
1. Navigate to your project's
2. Create a new file named
3. Add the following script content to
4. Make the script executable:
Now, if you try to commit a file containing
Sharing Git Hooks
One challenge with Git hooks is that they are local to each repository clone and are not version-controlled by default (the
Team members would need to run this
Best Practices
Git hooks are an indispensable tool for maintaining code quality, enforcing standards, and automating repetitive tasks in your development workflow. By integrating them thoughtfully, teams can significantly reduce errors and improve overall productivity.
.git/hooks directory, and offer a fantastic way to automate tasks, enforce coding standards, and streamline your development workflow. Understanding and leveraging them can significantly improve code quality and team collaboration.What are Git Hooks?
Essentially, Git hooks are executable scripts (typically shell scripts, but can be in any language your system can execute, like Python, Ruby, or Node.js) that get triggered by specific Git events. When you initialize a new Git repository, Git populates the
.git/hooks directory with sample scripts (e.g., pre-commit.sample, post-update.sample). To activate a hook, you simply remove the .sample extension and make the script executable.Types of Git Hooks
Git hooks are broadly categorized into client-side and server-side hooks.
Client-Side Hooks: These run on your local repository and are triggered by operations like committing and merging.
pre-commit: Runs *before* a commit. Ideal for linting code, running tests, or checking for large files. If this script exits with a non-zero status, the commit is aborted.prepare-commit-msg: Runs *after thepre-commithook but before* the commit message editor is launched. Useful for pre-populating the commit message.commit-msg: Runs *after the commit message has been entered but before* the commit is finalized. Excellent for enforcing commit message format (e.g., conventional commits).post-commit: Runs *after* a commit is successfully created. Can be used for notification, logging, or updating external systems.pre-rebase: Runs *before*git rebasestarts. Prevents rebasing if certain conditions aren't met.post-checkout: Runs *after*git checkout. Useful for setting up your working directory based on the branch (e.g., installing dependencies).pre-push: Runs *before*git push. A critical hook for running integration tests or ensuring all local changes are squashed. If it exits non-zero, the push is aborted.
Server-Side Hooks: These run on the remote repository server and are triggered by network operations like pushing. They are crucial for enforcing repository policies and continuous integration.
pre-receive: Runs *before* any references are updated on the remote. Can reject pushes based on branch names, commit authors, or file content.update: Similar topre-receivebut runs once per pushed branch. Gives more granular control over which branches are allowed to be updated.post-receive: Runs *after* a successful push. Commonly used for deploying code, triggering CI/CD pipelines, or sending notifications.
Implementing a Basic Client-Side Hook
Let's create a simple
pre-commit hook that checks for common debugging statements (like console.log or debugger;) before allowing a commit.1. Navigate to your project's
.git/hooks directory:
Code:
bash
cd .git/hookspre-commit (or rename pre-commit.sample):
Code:
bash
touch pre-commitpre-commit:
Code:
bash
#!/bin/sh
# Get a list of all staged files
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM)
# Define patterns to search for
DEBUG_PATTERNS="console.log\|debugger;\|binding.pry"
for FILE in $STAGED_FILES
do
# Check if the file exists and is not binary
if [ -f "$FILE" ] && ! git diff --cached --name-only -z "$FILE" | grep -q '\.bin$'; then
if grep -qE "$DEBUG_PATTERNS" "$FILE"; then
echo "Error: Found debugging statements in $FILE"
echo "Please remove them before committing."
exit 1
fi
fi
done
exit 0
Code:
bash
chmod +x pre-commitNow, if you try to commit a file containing
console.log, the commit will be aborted with an error message.Sharing Git Hooks
One challenge with Git hooks is that they are local to each repository clone and are not version-controlled by default (the
.git directory is excluded). This means teammates don't automatically get your hooks. Here are common strategies to share hooks:core.hooksPath: Git 2.9+ introducedgit config core.hooksPath. You can point this to a directory *within your repository that is* version-controlled.
Code:
bash
# In your project root, create a 'githooks' directory
mkdir githooks
# Add your hooks to githooks/
# Then configure Git to use it
git config core.hooksPath githooksgit config command once after cloning.- Dedicated Hook Managers: Tools like Husky (for Node.js projects) or
pre-commit(a Python framework) simplify managing and sharing hooks by integrating them into your project'spackage.jsonorconfig.yamlrespectively. They handle installing the hooks for users automatically. - Setup Script: Include a setup script (e.g.,
setup.sh) in your repository that copies the hook files from a version-controlled directory into.git/hooksand makes them executable. New developers would run this script after cloning.
Best Practices
- Keep Hooks Fast: Hooks run on every relevant Git operation. Slow hooks can frustrate developers. Optimize them for speed.
- Provide Clear Feedback: If a hook fails, the message should clearly explain *why and how* to fix it.
- Idempotency: Hooks should ideally be idempotent, meaning running them multiple times yields the same result without side effects.
- Don't Modify Commits Unnecessarily: Client-side hooks should avoid altering commit history without explicit user intent.
- Version Control Your Hook Scripts: Even if you're manually copying them, keep the source scripts in your repository.
Git hooks are an indispensable tool for maintaining code quality, enforcing standards, and automating repetitive tasks in your development workflow. By integrating them thoughtfully, teams can significantly reduce errors and improve overall productivity.