Introduction

Yes, Git hook scripts can be managed alongside the repository, but not by committing files directly into .git/hooks. The normal approach is to store hook scripts in a tracked directory and point Git at that directory with configuration or a hook-management tool.

Why .git/hooks Is Not Versioned

The .git directory is local repository metadata, not tracked project content. That is why hook files placed directly in .git/hooks do not travel with clones, pulls, or merges.

So if you want team-wide hook management, you need a pattern like:

• commit hooks under a normal tracked folder
• configure Git to use that folder
• make setup part of the project bootstrap process

Use core.hooksPath

Git supports changing the hook directory with core.hooksPath. This is the most direct built-in solution.

Create a tracked folder:

mkdir -p .githooks

Add a hook script:

1cat > .githooks/pre-commit <<'EOF'
2#!/bin/sh
3echo "Running checks before commit"
4npm test
5EOF
6
7chmod +x .githooks/pre-commit

Then tell Git to use it:

git config core.hooksPath .githooks

From that point on, Git reads hooks from the tracked .githooks directory instead of .git/hooks.

What This Buys You

Managing hooks in the repository means:

• everyone can review hook changes in normal commits
• the scripts evolve with the codebase
• new contributors can install the same hooks consistently

That is much better than asking every developer to hand-copy scripts into .git/hooks.

You Still Need a Setup Step

One important limitation remains: configuration is local. Cloning the repository does not automatically set core.hooksPath for every developer unless your setup process does it.

A common bootstrap step is:

git config core.hooksPath .githooks

Many teams place that in:

• onboarding docs
• a make setup target
• a repository setup script

The hook files are versioned, but the local Git config still has to point at them.

Example Hook for Formatting

Here is a simple pre-commit hook that blocks a commit when formatting fails:

1#!/bin/sh
2echo "Checking formatting..."
3
4if ! npm run lint; then
5  echo "Lint failed"
6  exit 1
7fi

Because the script lives in the repository, changes to the hook can be reviewed just like application code.

Tooling Alternatives

Some ecosystems use dedicated tools instead of raw core.hooksPath. Examples include hook managers that install scripts automatically during dependency setup. Those tools can improve onboarding, but the core idea is the same:

• keep the canonical hook definitions in version control
• install or point Git to them locally

If your team already uses one of those tools, follow that convention instead of layering another system on top.

Be Careful With Portability

Hooks run on each developer's machine, so portability matters. A shell script that assumes a very specific environment may fail on another operating system or shell.

To keep hooks maintainable:

• use portable shell where possible
• keep scripts fast
• print clear failure messages
• avoid requiring huge toolchains for simple checks

A slow or fragile hook is often bypassed, which defeats the point of managing it centrally.

Common Pitfalls

The most common mistake is committing hook files into the repository and assuming Git will automatically execute them. Git does not read tracked files as hooks unless configured to do so.

Another issue is forgetting the executable bit. A hook file without execute permissions is ignored even when it sits in the right hook directory.

Teams also build hooks that depend on local tools nobody has installed. Versioning the script is helpful, but it does not solve environment drift by itself.

Summary

• Yes, Git hooks can be managed with the repository by storing them in a tracked directory.
• Use git config core.hooksPath .githooks to point Git at the versioned hook folder.
• Hook files still need execute permissions.
• Clones still need a local setup step unless another tool installs the config automatically.
• Keep hooks portable and fast so developers do not work around them.