The first four hooks have to do with the committing process.

Thepre-commit hook is run first, before you even type in a commit message.It’s used to inspect the snapshot that’s about to be committed, to see if you’ve forgotten something, to make sure tests run, or to examine whatever you need to inspect in the code.Exiting non-zero from this hook aborts the commit, although you can bypass it withgit commit --no-verify.You can do things like check for code style (runlint or something equivalent), check for trailing whitespace (the default hook does exactly this), or check for appropriate documentation on new methods.

Theprepare-commit-msg hook is run before the commit message editor is fired up but after the default message is created.It lets you edit the default message before the commit author sees it.This hook takes a few parameters: the path to the file that holds the commit message so far, the type of commit, and the commit SHA-1 if this is an amended commit.This hook generally isn’t useful for normal commits; rather, it’s good for commits where the default message is auto-generated, such as templated commit messages, merge commits, squashed commits, and amended commits.You may use it in conjunction with a commit template to programmatically insert information.

Thecommit-msg hook takes one parameter, which again is the path to a temporary file that contains the commit message written by the developer.If this script exits non-zero, Git aborts the commit process, so you can use it to validate your project state or commit message before allowing a commit to go through.In the last section of this chapter, we’ll demonstrate using this hook to check that your commit message is conformant to a required pattern.

After the entire commit process is completed, thepost-commit hook runs.It doesn’t take any parameters, but you can easily get the last commit by runninggit log -1 HEAD.Generally, this script is used for notification or something similar.

You can set up three client-side hooks for an email-based workflow.They’re all invoked by thegit am command, so if you aren’t using that command in your workflow, you can safely skip to the next section.If you’re taking patches over email prepared bygit format-patch, then some of these may be helpful to you.

The first hook that is run isapplypatch-msg.It takes a single argument: the name of the temporary file that contains the proposed commit message.Git aborts the patch if this script exits non-zero.You can use this to make sure a commit message is properly formatted, or to normalize the message by having the script edit it in place.

The next hook to run when applying patches viagit am ispre-applypatch.Somewhat confusingly, it is runafter the patch is applied but before a commit is made, so you can use it to inspect the snapshot before making the commit.You can run tests or otherwise inspect the working tree with this script.If something is missing or the tests don’t pass, exiting non-zero aborts thegit am script without committing the patch.

The last hook to run during agit am operation ispost-applypatch, which runs after the commit is made.You can use it to notify a group or the author of the patch you pulled in that you’ve done so.You can’t stop the patching process with this script.

Thepre-rebase hook runs before you rebase anything and can halt the process by exiting non-zero.You can use this hook to disallow rebasing any commits that have already been pushed.The examplepre-rebase hook that Git installs does this, although it makes some assumptions that may not match with your workflow.

Thepost-rewrite hook is run by commands that replace commits, such asgit commit --amend andgit rebase (though not bygit filter-branch).Its single argument is which command triggered the rewrite, and it receives a list of rewrites onstdin.This hook has many of the same uses as thepost-checkout andpost-merge hooks.

After you run a successfulgit checkout, thepost-checkout hook runs; you can use it to set up your working directory properly for your project environment.This may mean moving in large binary files that you don’t want source controlled, auto-generating documentation, or something along those lines.

Thepost-merge hook runs after a successfulmerge command.You can use it to restore data in the working tree that Git can’t track, such as permissions data.This hook can likewise validate the presence of files external to Git control that you may want copied in when the working tree changes.

Thepre-push hook runs duringgit push, after the remote refs have been updated but before any objects have been transferred.It receives the name and location of the remote as parameters, and a list of to-be-updated refs throughstdin.You can use it to validate a set of ref updates before a push occurs (a non-zero exit code will abort the push).

Git occasionally does garbage collection as part of its normal operation, by invokinggit gc --auto.Thepre-auto-gc hook is invoked just before the garbage collection takes place, and can be used to notify you that this is happening, or to abort the collection if now isn’t a good time.

The first script to run when handling a push from a client ispre-receive.It takes a list of references that are being pushed from stdin; if it exits non-zero, none of them are accepted.You can use this hook to do things like make sure none of the updated references are non-fast-forwards, or to do access control for all the refs and files they’re modifying with the push.

Theupdate script is very similar to thepre-receive script, except that it’s run once for each branch the pusher is trying to update.If the pusher is trying to push to multiple branches,pre-receive runs only once, whereasupdate runs once per branch they’re pushing to.Instead of reading from stdin, this script takes three arguments: the name of the reference (branch), the SHA-1 that reference pointed to before the push, and the SHA-1 the user is trying to push.If theupdate script exits non-zero, only that reference is rejected; other references can still be updated.

Thepost-receive hook runs after the entire process is completed and can be used to update other services or notify users.It takes the same stdin data as thepre-receive hook.Examples include emailing a list, notifying a continuous integration server, or updating a ticket-tracking system – you can even parse the commit messages to see if any tickets need to be opened, modified, or closed.This script can’t stop the push process, but the client doesn’t disconnect until it has completed, so be careful if you try to do anything that may take a long time.