Module 8: Automation, Hooks, Signing, and Productivity
Local Hooks and Pre-commit Quality Gates
Local Hooks and Pre-commit Quality Gates
Module: Module 8: Automation, Hooks, Signing, and Productivity
Git hooks run scripts at lifecycle points such as pre-commit, commit-msg, pre-push, and post-merge. Local hooks can catch mistakes before they leave a developer machine.
Hooks in .git/hooks are not versioned by default, so teams usually use a hook manager or a repository script that installs hooks. A pre-commit hook can run formatting, linting, or secret detection. A commit-msg hook can enforce message format. A pre-push hook can run a smaller test suite before network push.
Hooks should be helpful, fast, and reproducible in CI. If a hook is slow or flaky, developers will bypass it. Use hooks as early feedback, not as the only enforcement layer. CI remains the shared source of truth.
Command Walkthrough
ls .git/hooks
cat > .git/hooks/pre-commit.sample
chmod +x .git/hooks/pre-commit
git commit --no-verify
git config core.hooksPath .githooks[main d4e5f6a] Add focused change
1 file changed, 2 insertions(+)Hands-on Lab
Create a versioned .githooks/pre-commit script that runs ./scripts/test.sh. Configure core.hooksPath for the practice repository and verify that a failing test blocks commit.
What to Watch For
- Local hooks can be bypassed. Critical policy belongs in CI or server-side checks.
- Do not make hooks depend on tools that are undocumented or hard to install.
- Keep hook output short and actionable.
Completion Check
You should be able to explain what each command changed, inspect the resulting history, and describe how you would undo or recover from the operation before using it in a shared repository.