manpagez: man pages & more
man git-hook(1)
Home | html | info | man
git-hook(1)                       Git Manual                       git-hook(1)


NAME

       git-hook - Run git hooks


SYNOPSIS

       git hook run [--allow-unknown-hook-name] [--ignore-missing] [--to-stdin=<path>] <hook-name> [-- <hook-args>]
       git hook list [--allow-unknown-hook-name] [-z] [--show-scope] <hook-name>


DESCRIPTION

       A command interface for running git hooks (see githooks(5)), for use by
       other scripted git commands.

       This command parses the default configuration files for sets of configs
       like so:

           [hook "linter"]
             event = pre-commit
             command = ~/bin/linter --cpp20

       In this example, [hook "linter"] represents one script - ~/bin/linter
       --cpp20 - which can be shared by many repos, and even by many hook
       events, if appropriate.

       To add an unrelated hook which runs on a different event, for example a
       spell-checker for your commit messages, you would write a configuration
       like so:

           [hook "linter"]
             event = pre-commit
             command = ~/bin/linter --cpp20
           [hook "spellcheck"]
             event = commit-msg
             command = ~/bin/spellchecker

       With this config, when you run git commit, first ~/bin/linter --cpp20
       will have a chance to check your files to be committed (during the
       pre-commit hook event`), and then ~/bin/spellchecker will have a chance
       to check your commit message (during the commit-msg hook event).

       Commands are run in the order Git encounters their associated
       hook.<friendly-name>.event configs during the configuration parse (see
       git-config(1)). Although multiple hook.linter.event configs can be
       added, only one hook.linter.command event is valid - Git uses
       "last-one-wins" to determine which command to run.

       So if you wanted your linter to run when you commit as well as when you
       push, you would configure it like so:

           [hook "linter"]
             event = pre-commit
             event = pre-push
             command = ~/bin/linter --cpp20

       With this config, ~/bin/linter --cpp20 would be run by Git before a
       commit is generated (during pre-commit) as well as before a push is
       performed (during pre-push).

       And if you wanted to run your linter as well as a secret-leak detector
       during only the "pre-commit" hook event, you would configure it instead
       like so:

           [hook "linter"]
             event = pre-commit
             command = ~/bin/linter --cpp20
           [hook "no-leaks"]
             event = pre-commit
             command = ~/bin/leak-detector

       With this config, before a commit is generated (during pre-commit), Git
       would first start ~/bin/linter --cpp20 and second start
       ~/bin/leak-detector. It would evaluate the output of each when deciding
       whether to proceed with the commit.

       For a full list of hook events which you can set your
       hook.<friendly-name>.event to, and how hooks are invoked during those
       events, see githooks(5).

       Git will ignore any hook.<friendly-name>.event that specifies an event
       it doesn't recognize. This is intended so that tools which wrap Git can
       use the hook infrastructure to run their own hooks; see "WRAPPERS" for
       more guidance.

       In general, when instructions suggest adding a script to
       .git/hooks/<hook-event>, you can specify it in the config instead by
       running:

           git config set hook.<some-name>.command <path-to-script>
           git config set --append hook.<some-name>.event <hook-event>

       This way you can share the script between multiple repos. That is, cp
       ~/my-script.sh ~/project/.git/hooks/pre-commit would become:

           git config set hook.my-script.command ~/my-script.sh
           git config set --append hook.my-script.event pre-commit


SUBCOMMANDS

       run
           Runs hooks configured for <hook-name>, in the order they are
           discovered during the config parse. The default <hook-name> from
           the hookdir is run last. See githooks(5) for supported hook names.

           Any positional arguments to the hook should be passed after a
           mandatory -- (or --end-of-options, see gitcli(7)). See githooks(5)
           for arguments hooks might expect (if any).

       list [-z] [--show-scope]
           Print a list of hooks which will be run on <hook-name> event. If no
           hooks are configured for that event, print a warning and return 1.
           Use -z to terminate output lines with NUL instead of newlines.


OPTIONS

       --allow-unknown-hook-name
           By default git hook run and git hook list will bail out when
           <hook-name> is not a hook event known to Git (see githooks(5) for
           the list of known hooks). This is meant to help catch typos such as
           prereceive when pre-receive was intended. Pass this flag to allow
           unknown hook names.

       --to-stdin
           For "run"; specify a file which will be streamed into the hook's
           stdin. The hook will receive the entire file from beginning to EOF.

       --ignore-missing
           Ignore any missing hook by quietly returning zero. Used for tools
           that want to do a blind one-shot run of a hook that may or may not
           be present.

       -z
           Terminate "list" output lines with NUL instead of newlines.

       --show-scope
           For "list"; prefix each configured hook's friendly name with a
           tab-separated config scope (e.g.  local, global, system), mirroring
           the output style of git config --show-scope. Traditional hooks from
           the hookdir are unaffected.


WRAPPERS

       git hook run has been designed to make it easy for tools which wrap Git
       to configure and execute hooks using the Git hook infrastructure. It is
       possible to provide arguments and stdin via the command line, as well
       as specifying parallel or series execution if the user has provided
       multiple hooks.

       Assuming your wrapper wants to support a hook named
       "mywrapper-start-tests", you can have your users specify their hooks
       like so:

           [hook "setup-test-dashboard"]
             event = mywrapper-start-tests
             command = ~/mywrapper/setup-dashboard.py --tap

       Then, in your mywrapper tool, you can invoke any users' configured
       hooks by running:

           git hook run --allow-unknown-hook-name mywrapper-start-tests \
             # providing something to stdin
             --stdin some-tempfile-123 \
             # execute hooks in serial
             # plus some arguments of your own...
             -- \
             --testname bar \
             baz

       Take care to name your wrapper's hook events in a way which is unlikely
       to overlap with Git's native hooks (see githooks(5)) - a hook event
       named mywrappertool-validate-commit is much less likely to be added to
       native Git than a hook event named validate-commit. If Git begins to
       use a hook event named the same thing as your wrapper hook, it may
       invoke your users' hooks in unintended and unsupported ways.


CONFIGURATION

       hook.<friendly-name>.command
           The command to execute for hook.<friendly-name>.  <friendly-name>
           is a unique name that identifies this hook. The hook events that
           trigger the command are configured with hook.<friendly-name>.event.
           The value can be an executable path or a shell oneliner. If more
           than one value is specified for the same <friendly-name>, only the
           last value parsed is used. See git-hook(1).

       hook.<friendly-name>.event
           The hook events that trigger hook.<friendly-name>. The value is the
           name of a hook event, like "pre-commit" or "update". (See
           githooks(5) for a complete list of hook events.) On the specified
           event, the associated hook.<friendly-name>.command is executed.
           This is a multi-valued key. To run hook.<friendly-name> on multiple
           events, specify the key more than once. An empty value resets the
           list of events, clearing any previously defined events for
           git-hook(1).

       hook.<friendly-name>.enabled
           Whether the hook hook.<friendly-name> is enabled. Defaults to true.
           Set to false to disable the hook without removing its
           configuration. This is particularly useful when a hook is defined
           in a system or global config file and needs to be disabled for a
           specific repository. See git-hook(1).


SEE ALSO

       githooks(5)


GIT

       Part of the git(1) suite

Git 2.54.0                        2026-04-19                       git-hook(1)

git 2.54.0 - Generated Thu Apr 23 16:45:48 CDT 2026
© manpagez.com 2000-2026
Individual documents may contain additional copyright information.