1githooks(5) 2=========== 3 4NAME 5---- 6githooks - Hooks used by git 7 8SYNOPSIS 9-------- 10$GIT_DIR/hooks/* 11 12 13DESCRIPTION 14----------- 15 16Hooks are little scripts you can place in `$GIT_DIR/hooks` 17directory to trigger action at certain points. When 18'git-init' is run, a handful of example hooks are copied into the 19`hooks` directory of the new repository, but by default they are 20all disabled. To enable a hook, rename it by removing its `.sample` 21suffix. 22 23NOTE: It is also a requirement for a given hook to be executable. 24However - in a freshly initialized repository - the `.sample` files are 25executable by default. 26 27This document describes the currently defined hooks. 28 29applypatch-msg 30-------------- 31 32This hook is invoked by 'git-am' script. It takes a single 33parameter, the name of the file that holds the proposed commit 34log message. Exiting with non-zero status causes 35'git-am' to abort before applying the patch. 36 37The hook is allowed to edit the message file in place, and can 38be used to normalize the message into some project standard 39format (if the project has one). It can also be used to refuse 40the commit after inspecting the message file. 41 42The default 'applypatch-msg' hook, when enabled, runs the 43'commit-msg' hook, if the latter is enabled. 44 45pre-applypatch 46-------------- 47 48This hook is invoked by 'git-am'. It takes no parameter, and is 49invoked after the patch is applied, but before a commit is made. 50 51If it exits with non-zero status, then the working tree will not be 52committed after applying the patch. 53 54It can be used to inspect the current working tree and refuse to 55make a commit if it does not pass certain test. 56 57The default 'pre-applypatch' hook, when enabled, runs the 58'pre-commit' hook, if the latter is enabled. 59 60post-applypatch 61--------------- 62 63This hook is invoked by 'git-am'. It takes no parameter, 64and is invoked after the patch is applied and a commit is made. 65 66This hook is meant primarily for notification, and cannot affect 67the outcome of 'git-am'. 68 69pre-commit 70---------- 71 72This hook is invoked by 'git-commit', and can be bypassed 73with `\--no-verify` option. It takes no parameter, and is 74invoked before obtaining the proposed commit log message and 75making a commit. Exiting with non-zero status from this script 76causes the 'git-commit' to abort. 77 78The default 'pre-commit' hook, when enabled, catches introduction 79of lines with trailing whitespaces and aborts the commit when 80such a line is found. 81 82All the 'git-commit' hooks are invoked with the environment 83variable `GIT_EDITOR=:` if the command will not bring up an editor 84to modify the commit message. 85 86prepare-commit-msg 87------------------ 88 89This hook is invoked by 'git-commit' right after preparing the 90default log message, and before the editor is started. 91 92It takes one to three parameters. The first is the name of the file 93that contains the commit log message. The second is the source of the commit 94message, and can be: `message` (if a `-m` or `-F` option was 95given); `template` (if a `-t` option was given or the 96configuration option `commit.template` is set); `merge` (if the 97commit is a merge or a `.git/MERGE_MSG` file exists); `squash` 98(if a `.git/SQUASH_MSG` file exists); or `commit`, followed by 99a commit SHA1 (if a `-c`, `-C` or `\--amend` option was given). 100 101If the exit status is non-zero, 'git-commit' will abort. 102 103The purpose of the hook is to edit the message file in place, and 104it is not suppressed by the `\--no-verify` option. A non-zero exit 105means a failure of the hook and aborts the commit. It should not 106be used as replacement for pre-commit hook. 107 108The sample `prepare-commit-msg` hook that comes with git comments 109out the `Conflicts:` part of a merge's commit message. 110 111commit-msg 112---------- 113 114This hook is invoked by 'git-commit', and can be bypassed 115with `\--no-verify` option. It takes a single parameter, the 116name of the file that holds the proposed commit log message. 117Exiting with non-zero status causes the 'git-commit' to 118abort. 119 120The hook is allowed to edit the message file in place, and can 121be used to normalize the message into some project standard 122format (if the project has one). It can also be used to refuse 123the commit after inspecting the message file. 124 125The default 'commit-msg' hook, when enabled, detects duplicate 126"Signed-off-by" lines, and aborts the commit if one is found. 127 128post-commit 129----------- 130 131This hook is invoked by 'git-commit'. It takes no 132parameter, and is invoked after a commit is made. 133 134This hook is meant primarily for notification, and cannot affect 135the outcome of 'git-commit'. 136 137pre-rebase 138---------- 139 140This hook is called by 'git-rebase' and can be used to prevent a branch 141from getting rebased. 142 143 144post-checkout 145----------- 146 147This hook is invoked when a 'git-checkout' is run after having updated the 148worktree. The hook is given three parameters: the ref of the previous HEAD, 149the ref of the new HEAD (which may or may not have changed), and a flag 150indicating whether the checkout was a branch checkout (changing branches, 151flag=1) or a file checkout (retrieving a file from the index, flag=0). 152This hook cannot affect the outcome of 'git-checkout'. 153 154It is also run after 'git-clone', unless the --no-checkout (-n) option is 155used. The first parameter given to the hook is the null-ref, the second the 156ref of the new HEAD and the flag is always 1. 157 158This hook can be used to perform repository validity checks, auto-display 159differences from the previous HEAD if different, or set working dir metadata 160properties. 161 162post-merge 163----------- 164 165This hook is invoked by 'git-merge', which happens when a 'git-pull' 166is done on a local repository. The hook takes a single parameter, a status 167flag specifying whether or not the merge being done was a squash merge. 168This hook cannot affect the outcome of 'git-merge' and is not executed, 169if the merge failed due to conflicts. 170 171This hook can be used in conjunction with a corresponding pre-commit hook to 172save and restore any form of metadata associated with the working tree 173(eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl 174for an example of how to do this. 175 176[[pre-receive]] 177pre-receive 178----------- 179 180This hook is invoked by 'git-receive-pack' on the remote repository, 181which happens when a 'git-push' is done on a local repository. 182Just before starting to update refs on the remote repository, the 183pre-receive hook is invoked. Its exit status determines the success 184or failure of the update. 185 186This hook executes once for the receive operation. It takes no 187arguments, but for each ref to be updated it receives on standard 188input a line of the format: 189 190 <old-value> SP <new-value> SP <ref-name> LF 191 192where `<old-value>` is the old object name stored in the ref, 193`<new-value>` is the new object name to be stored in the ref and 194`<ref-name>` is the full name of the ref. 195When creating a new ref, `<old-value>` is 40 `0`. 196 197If the hook exits with non-zero status, none of the refs will be 198updated. If the hook exits with zero, updating of individual refs can 199still be prevented by the <<update,'update'>> hook. 200 201Both standard output and standard error output are forwarded to 202'git-send-pack' on the other end, so you can simply `echo` messages 203for the user. 204 205[[update]] 206update 207------ 208 209This hook is invoked by 'git-receive-pack' on the remote repository, 210which happens when a 'git-push' is done on a local repository. 211Just before updating the ref on the remote repository, the update hook 212is invoked. Its exit status determines the success or failure of 213the ref update. 214 215The hook executes once for each ref to be updated, and takes 216three parameters: 217 218 - the name of the ref being updated, 219 - the old object name stored in the ref, 220 - and the new objectname to be stored in the ref. 221 222A zero exit from the update hook allows the ref to be updated. 223Exiting with a non-zero status prevents 'git-receive-pack' 224from updating that ref. 225 226This hook can be used to prevent 'forced' update on certain refs by 227making sure that the object name is a commit object that is a 228descendant of the commit object named by the old object name. 229That is, to enforce a "fast forward only" policy. 230 231It could also be used to log the old..new status. However, it 232does not know the entire set of branches, so it would end up 233firing one e-mail per ref when used naively, though. The 234<<post-receive,'post-receive'>> hook is more suited to that. 235 236Another use suggested on the mailing list is to use this hook to 237implement access control which is finer grained than the one 238based on filesystem group. 239 240Both standard output and standard error output are forwarded to 241'git-send-pack' on the other end, so you can simply `echo` messages 242for the user. 243 244The default 'update' hook, when enabled--and with 245`hooks.allowunannotated` config option turned on--prevents 246unannotated tags to be pushed. 247 248[[post-receive]] 249post-receive 250------------ 251 252This hook is invoked by 'git-receive-pack' on the remote repository, 253which happens when a 'git-push' is done on a local repository. 254It executes on the remote repository once after all the refs have 255been updated. 256 257This hook executes once for the receive operation. It takes no 258arguments, but gets the same information as the 259<<pre-receive,'pre-receive'>> 260hook does on its standard input. 261 262This hook does not affect the outcome of 'git-receive-pack', as it 263is called after the real work is done. 264 265This supersedes the <<post-update,'post-update'>> hook in that it gets 266both old and new values of all the refs in addition to their 267names. 268 269Both standard output and standard error output are forwarded to 270'git-send-pack' on the other end, so you can simply `echo` messages 271for the user. 272 273The default 'post-receive' hook is empty, but there is 274a sample script `post-receive-email` provided in the `contrib/hooks` 275directory in git distribution, which implements sending commit 276emails. 277 278[[post-update]] 279post-update 280----------- 281 282This hook is invoked by 'git-receive-pack' on the remote repository, 283which happens when a 'git-push' is done on a local repository. 284It executes on the remote repository once after all the refs have 285been updated. 286 287It takes a variable number of parameters, each of which is the 288name of ref that was actually updated. 289 290This hook is meant primarily for notification, and cannot affect 291the outcome of 'git-receive-pack'. 292 293The 'post-update' hook can tell what are the heads that were pushed, 294but it does not know what their original and updated values are, 295so it is a poor place to do log old..new. The 296<<post-receive,'post-receive'>> hook does get both original and 297updated values of the refs. You might consider it instead if you need 298them. 299 300When enabled, the default 'post-update' hook runs 301'git-update-server-info' to keep the information used by dumb 302transports (e.g., HTTP) up-to-date. If you are publishing 303a git repository that is accessible via HTTP, you should 304probably enable this hook. 305 306Both standard output and standard error output are forwarded to 307'git-send-pack' on the other end, so you can simply `echo` messages 308for the user. 309 310pre-auto-gc 311----------- 312 313This hook is invoked by 'git-gc --auto'. It takes no parameter, and 314exiting with non-zero status from this script causes the 'git-gc --auto' 315to abort. 316 317GIT 318--- 319Part of the linkgit:git[1] suite