What's different between native Git hooks and Husky v9?

A native hook is a plain executable script placed directly at `.git/hooks/ `, it isn't tracked by Git or shared with teammates automatically. Husky v9 manages hook scripts under a tracked `.husky/` directory (installed via `npx husky init`), so the same hook is automatically set up for every contributor who runs `npm install`.

Why is the Husky v9 output just one line, with no shebang?

Husky v9 simplified its hook files considerably compared to earlier versions: there's no more `#!/usr/bin/env sh` line or sourcing `_/husky.sh`, a Husky v9 hook file is just the command(s) to run, directly. Husky's own CLI handles making the file executable when you run `npx husky init` or `chmod +x .husky/ ` once.

What does the commit-msg hook's $1 variable do?

Git invokes the commit-msg hook with a single argument: the path to a temporary file containing the commit message being validated. The generated native script captures this as `commit_msg_file="$1"` so you can extend the command to read and validate that file's contents (e.g. checking it matches a Conventional Commits pattern).

Do I need to make the generated file executable?

Yes, for a native hook run `chmod +x .git/hooks/ ` after saving the file. For Husky v9, running `npx husky init` sets this up automatically, and `chmod +x .husky/ ` covers it if you're adding a new hook file directly.

Git Hooks Generator - Build pre-commit, commit-msg, pre-push Scripts

Overview

Introduction

Git hook scripts are simple in principle, run a command before or after a Git action, but the boilerplate differs enough between a raw .git/hooks script and a Husky-managed one that it's easy to mix up the two conventions.

This tool generates a ready-to-save hook script for either target: a native .git/hooks script with the right shebang, or a Husky v9 script in its simplified modern format.

What Is Git Hooks Generator?

A generator for three common Git hook types, pre-commit (runs before a commit is created), commit-msg (validates the commit message itself), and pre-push (runs before pushing to a remote), targeting either a native .git/hooks script or a Husky v9 script.

You provide the command the hook should run (typically a lint or test command), and the tool wraps it with the correct boilerplate and file path for your chosen target.

How Git Hooks Generator Works

For a native target, the output includes a `#!/usr/bin/env sh` shebang and `set -e` (so the hook exits non-zero, and blocks the Git action, if your command fails), plus a `commit_msg_file="$1"` line specifically for the commit-msg hook type.

For a Husky v9 target, the output is just your command as-is, since Husky v9 dropped the shebang and sourcing boilerplate earlier versions required, the file just needs to be saved at `.husky/<hook-name>` and made executable.

When To Use Git Hooks Generator

Use it when setting up local quality gates, like running a linter before every commit or a test suite before every push, without hand-writing hook boilerplate you don't use often enough to remember.

It's also useful when migrating a team's hooks from raw .git/hooks scripts (not shared via version control) to Husky-managed hooks that install automatically for every contributor.

Often used alongside Conventional Commit Message Generator, .gitignore Generator and GitHub Actions Workflow Generator.

Features

Advantages

Generates the correct boilerplate for two meaningfully different hook management approaches, so you don't accidentally use Husky's old (pre-v9) shebang-and-sourcing convention on a v9 project, or vice versa.
Includes the `set -e` safety flag on native scripts so a failing command actually blocks the Git action, rather than the hook silently succeeding regardless.
Handles the commit-msg hook's special `$1` argument correctly, since it's easy to forget that this hook receives a file path rather than the message as a direct argument.

Limitations

Generates a single-command hook; hooks that need multiple independent checks with different failure messages need to be composed manually from multiple commands.
Doesn't install anything, it produces the script text only; you still need to save it to the right path and make it executable yourself.

Examples

A Husky v9 pre-commit hook running lint-staged

Input

hook: pre-commit, target: husky, command: npx lint-staged

Output

npx lint-staged

Husky v9 hook files are just the command itself, saved at .husky/pre-commit and made executable.

Best Practices & Notes

Best Practices

Prefer Husky (or an equivalent tracked-hooks tool) over raw .git/hooks scripts for anything a team needs to share, since .git/hooks isn't version-controlled by default.
Keep hook commands fast, a pre-commit hook that takes minutes to run will get skipped with `--no-verify` more often than it gets waited on.
Use pre-push rather than pre-commit for slower checks like a full test suite, so day-to-day commits stay fast while pushes still get validated.

Developer Notes

Native scripts use `#!/usr/bin/env sh` rather than a hard-coded shell path for portability across systems where `/bin/sh` might not be the intended shell resolution order, and `set -e` ensures the script's exit code reflects the last failing command, which Git relies on to decide whether to block the corresponding action. The commit-msg hook's `commit_msg_file="$1"` line is emitted purely as a convenience/documentation aid, since Git always passes that path positionally regardless of whether the script captures it into a named variable.

Git Hooks Generator Use Cases

Adding a pre-commit lint/format check to a new project
Validating commit message format with a commit-msg hook before allowing a commit
Running the full test suite as a pre-push hook to catch failures before they reach a shared branch

Common Mistakes

Forgetting to `chmod +x` the generated hook file, Git silently skips non-executable hook scripts instead of erroring.
Mixing Husky's older pre-v9 shebang boilerplate into a v9 project's hook file, which can cause the hook to behave unexpectedly or fail depending on the installed Husky version.

Tips

If a hook needs to run multiple checks, chain them with `&&` in the command field so any failure stops the whole hook and blocks the Git action, rather than silently continuing past a failed step.

Git Hooks Generator