Introduction

Git hooks are useful for enforcing checks and automating tasks, but there is one important limitation: the .git/hooks directory is not part of the repository history. That means simply adding hook scripts there does not share them with other clones. To put hooks "into a repository" in a practical sense, you usually version the scripts in a normal tracked directory and then configure Git to use that directory as the hooks path.

Why .git/hooks Is Not Enough

The default hooks live under .git/hooks, which is inside the local repository metadata directory. Git does not clone that directory as project content.

That is why a hook you wrote locally works for you but disappears for everyone else. The repository stores tracked files, not your local hook installation state.

Version the Hook Scripts in the Repository

A common pattern is to store the hook scripts in a tracked folder such as .githooks.

1mkdir -p .githooks
2cat > .githooks/pre-commit <<'EOF_HOOK'
3#!/bin/sh
4npm test
5EOF_HOOK
6chmod +x .githooks/pre-commit

Now the script itself is versioned like any other project file.

Point Git at the Versioned Hook Directory

Once the scripts are in the repository, configure Git to use them.

git config core.hooksPath .githooks

From that point on, Git will look in .githooks instead of .git/hooks for hook scripts in that clone.

This is the key step. Versioning the files alone does not activate them.

Make Setup Explicit for Other Clones

Repository content can store the scripts, but Git configuration still happens per clone. That means a new contributor usually needs a setup step after cloning, unless your tooling performs it automatically.

A common solution is to provide a bootstrap script or documented setup command.

./scripts/setup-hooks.sh

Inside that script, you can run git config core.hooksPath .githooks.

That setup step is worth treating as part of repository onboarding, not as tribal knowledge. If the team depends on hooks, installing them should be routine and documented.

Predictability is the real goal here.

Keep Hooks Fast and Predictable

Hooks that run too slowly or behave inconsistently will be bypassed or disabled. The best hooks are targeted, fast, and easy to understand.

For example, a pre-commit hook that formats changed files or runs a quick linter is often reasonable. A hook that performs a long integration suite on every commit is often too heavy.

That is not just a developer-experience issue. Reliable enforcement depends on hooks being practical enough that the team actually keeps them enabled.

Server-Side Hooks Are Different

If the goal is policy enforcement that users cannot skip locally, server-side checks on push or in CI are stronger than client-side hooks. Client-side hooks are helpful, but they are advisory from a trust perspective because each clone controls its own configuration.

That is why many teams use local hooks for fast feedback and CI for final enforcement.

Common Pitfalls

• Putting scripts in .git/hooks and expecting them to be shared by the repository.
• Versioning hook scripts in the project tree without configuring core.hooksPath.
• Forgetting that hook activation is still per clone.
• Making hooks so slow or fragile that developers disable them.
• Treating client-side hooks as an unskippable enforcement boundary.

Summary

• The default .git/hooks directory is local metadata and is not versioned with the repository.
• To share hooks, store them in a tracked directory such as .githooks.
• Configure core.hooksPath so Git actually uses that directory.
• Provide a setup step or bootstrap script for new clones.
• Use CI or server-side checks when you need enforcement stronger than local convention.