What are Git hooks and what are common use cases?
Understand Git hooks: event-triggered scripts like pre-commit and pre-push, client vs server-side hooks, and real use cases for linting, tests, and policy.
Expected Interview Answer
Git hooks are scripts that Git runs automatically at specific points in the version-control lifecycle — such as before a commit, before a push, or after a merge — letting you enforce policies and automate tasks.
They live in the .git/hooks directory (or a shared path set via core.hooksPath) and are named by the event they fire on, like pre-commit or commit-msg. Client-side hooks run on a developer's machine for commit and checkout events, while server-side hooks like pre-receive run on the remote to gate what gets accepted. Because local hooks are not cloned with the repo, teams distribute them with tools like Husky or pre-commit.
- Automate linting, formatting and tests before code is committed
- Enforce commit-message conventions
- Block secrets or broken builds from being pushed
- Trigger deployments or notifications after events
- Standardize quality checks across a team
AI Mentor Explanation
Git hooks are like the on-field umpires who check conditions at fixed moments before play proceeds. Before each over the umpire inspects the ball and confirms the field is legal; only if everything passes does the bowler run in. A pre-commit hook works the same way — it inspects your changes at the decisive moment and refuses to let the delivery go ahead unless the checks are satisfied.
Step-by-Step Explanation
Step 1
Understand the hook directory
Each repo has a .git/hooks folder with sample scripts named after events; remove the .sample suffix to activate one.
Step 2
Pick the right event
Client-side (pre-commit, commit-msg, pre-push) run locally; server-side (pre-receive, update, post-receive) run on the remote.
Step 3
Write an executable script
Any language works via a shebang; make it executable with chmod +x and exit non-zero to abort the action.
Step 4
Share hooks with the team
Because .git/hooks is not cloned, set core.hooksPath to a versioned folder, or use Husky / the pre-commit framework.
Step 5
Bypass when necessary
Use --no-verify to skip client hooks intentionally, but keep server-side hooks as the non-bypassable enforcement layer.
What Interviewer Expects
- Definition of hooks as event-triggered scripts
- Knowing they live in .git/hooks or core.hooksPath
- Distinguishing client-side from server-side hooks
- Real use cases like linting, tests, commit-message checks
- Awareness that local hooks aren't cloned and how teams share them
Common Mistakes
- Assuming hooks are cloned and shared automatically with the repo
- Confusing client-side hooks with server-side hooks
- Forgetting to make the hook script executable
- Not returning a non-zero exit code to actually block the action
- Relying only on local hooks for security instead of server-side enforcement
Best Answer (HR Friendly)
“Git hooks are small scripts that run automatically at certain points, like right before you save a commit or send code to the server. Teams use them to catch problems early — for example running the code formatter, checking the commit message, or making sure tests pass before anything is shared.”
Code Example
# File: .git/hooks/pre-commit (must be executable)
#!/bin/sh
# Run the linter; abort the commit if it fails
npm run lint
if [ $? -ne 0 ]; then
echo "Lint failed - commit aborted."
exit 1
fi
exit 0# Enable one of Git's sample hooks
cd .git/hooks
mv pre-commit.sample pre-commit
chmod +x pre-commit
# Share hooks via a versioned folder (works because .git/hooks is not cloned)
git config core.hooksPath .githooks
# Skip client-side hooks intentionally for one commit
git commit --no-verify -m "wip"Follow-up Questions
- What is the difference between pre-commit and pre-push hooks?
- Why aren't Git hooks shared when you clone a repository, and how do teams solve it?
- What does core.hooksPath do?
- How does the pre-receive hook enforce policy on a server?
- When is it appropriate to use --no-verify?
MCQ Practice
1. Where do a repository's default hooks live?
By default Git looks in .git/hooks; core.hooksPath can redirect it to a versioned folder.
2. Which hook runs on the server to accept or reject pushed commits?
pre-receive is a server-side hook that inspects incoming refs and can reject the entire push.
3. How does a hook abort the action it is attached to?
A non-zero exit code from the hook script tells Git to stop the commit, push, or other operation.
Flash Cards
What is a Git hook? — A script Git runs automatically at a lifecycle event like pre-commit, commit-msg, or pre-push.
Client-side vs server-side hooks? — Client-side run on the developer's machine (commit/checkout); server-side run on the remote (pre-receive) to gate pushes.
Why aren't hooks shared on clone? — .git/hooks isn't cloned; teams use core.hooksPath, Husky, or the pre-commit framework to share them.
How does a hook block an action? — It exits with a non-zero status code, which aborts the commit or push.