#  Global Hooks and Merge Checks

For users familiar with the [Git hook system](http://git-scm.com/book/en/Customizing-Git-Git-Hooks), Bitbucket Server provides a
way for plugin developers to create their own hooks that can be installed and managed without having to touch the
filesystem.

Hooks have been implemented using familiar modules within the Atlassian plugin system. Bitbucket Server also provides
[repository hooks](repository-hooks.html) which are easier to implement for simple use cases.

## Categories

Currently there are three types of hooks that are available in Bitbucket Server.

### Pre-receive

[Pre-receive Hook Modules](../reference/plugin-module-types/pre-receive-hook-plugin-module.html) are used to potentially block pushes to Bitbucket Server. An example might be to stop deletion of branches or
limit force-pushes to personal branches. Pre-receive hooks do not fire when a pull-request is merged - for that, you may
also want to implement a repository merge-check.


### Asynchronous Post-receive

[Post-receive Hook Modules](../reference/plugin-module-types/post-receive-hook-plugin-module.html) are invoked after a push _or_ merge has taken place. An example might be to notify a build server, such
as Bamboo, that there are new commits on a branch to be built.

Asynchronous post-receive hooks are preferred when there is no need to return any information to the client, as they are
triggered _after_ the push is complete. This is a better experience for the user as they will not have to wait for
potentially slow operations.

### Merge-checks

[Merge Check Modules](../reference/plugin-module-types/merge-check.html) are used to block pull requests from being merged until a required set of conditions have been met.
An example might be that all reviewers must accept the request, or that any associated builds are green.

#### How-to

[Merge check how-to](../tutorials-and-examples/controlling-when-pull-requests-can-be-merged.html)