At Yelp we rely heavily on pre-commit hooks to find and fix common issues before changes are submitted for code review. We run our hooks before every commit to automatically point out issues like missing semicolons, whitespace problems, and testing statements in code. Automatically fixing these issues before posting code reviews allows our code reviewer to pay attention to the architecture of a change and not worry about trivial errors.
As we created more libraries and projects we recognized that sharing our pre commit hooks across projects is painful. We copied and pasted bash scripts from project to project and had to manually change the hooks to work for different project structures.
We believe that you should always use the best industry standard linters. Some of the best linters are written in languages that you do not use in your project or have installed on your machine. For example scss-lint is a linter for SCSS written in Ruby. If you’re writing a project in node you should be able to use scss-lint as a pre-commit hook without adding a Gemfile to your project or understanding how to get scss-lint installed.
Before you can run hooks, you need to have the pre-commit package manager installed.
pip install pre-commit
Non Administrative Installation:
curl http://pre-commit.com/install-local.py | python
System Level Install:
curl https://bootstrap.pypa.io/get-pip.py | sudo python - pre-commit
In a Python Project, add the following to your requirements.txt (or requirements-dev.txt):
brew install pre-commit
Adding pre-commit plugins to your project
Once you have pre-commit installed, adding pre-commit plugins to your project is done with the
.pre-commit-config.yaml configuration file.
Add a file called
.pre-commit-config.yaml to the root of your project. The pre-commit config file describes:
||where to get plugins (git repos).
||What plugins from the repo you want to use.|
||(optional) Override the default language version for the hook. See Advanced Features: "Overriding Language Version".|
||(optional) Override the default pattern for files to run on.|
||(optional) File exclude pattern.|
||(optional) additional parameters to pass to the hook.|
||(optional) Confines the hook to the
||(optional) A list of dependencies that will be installed in the environment where this hook gets run. One useful application is to install plugins for hooks such as eslint. New in 0.6.6.|
- repo: git://github.com/pre-commit/pre-commit-hooks sha: v0.4.2 hooks: - id: trailing-whitespace
This configuration says to download the pre-commit-hooks project and run its trailing-whitespace hook.
Updating hooks automatically
You can update your hooks to the latest version automatically
pre-commit autoupdate. This will
bring the hooks to the latest sha on the master branch.
pre-commit install to install pre-commit into your git hooks. pre-commit will now run on every commit. Every time you clone a project using pre-commit running
pre-commit install should always be the first thing you do.
If you want to manually run all pre-commit hooks on a repository, run
pre-commit run --all-files. To run individual hooks use
pre-commit run <hook_id>.
The first time pre-commit runs on a file it will automatically download, install, and run the hook. Note that running a hook for the first time may be slow. For example: If the machine does not have node installed, pre-commit will download and build a copy of node.
Creating new hooks
An executable must satisfy the following things:
- The hook must exit nonzero on failure or modify files in the working directory (since 0.6.3).
- It must take filenames as positional arguments.
A git repo containing pre-commit plugins must contain a hooks.yaml file that tells pre-commit:
||The id of the hook - used in pre-commit-config.yaml|
||The name of the hook - shown during hook execution|
||The entry point - The executable to run|
||The pattern of files to run on.|
||The language of the hook - tells pre-commit how to install the hook.|
||(optional) The description of the hook.|
||(optional) See Advanced Features: "Overriding Language Version".|
||(optional) Allows one to indicate a minimum compatible pre-commit version. New in 0.6.7.|
- id: trailing-whitespace name: Trim Trailing Whitespace description: This hook trims trailing whitespace. entry: trailing-whitespace-fixer language: python files: \.(js|rb|md|py|sh|txt|yaml|yml)$
node- must have a package.json (Installed via
npm install .)
python- must have a setup.py (Installed via
pip install .)
ruby- must have a file matching *.gemspec (Installed via
gem build *.gemspec && gem install *.gem)
pcre- "Perl Compatible Regular Expression" Specify the regex as the
entry. For osx, you'll need
brew install grep
script- A script existing inside of a repository
system- Executables available at the system level
entryin your config.
node- provided by
python- usually provided by
ruby- provided by
executablesin your gemspec
Developing hooks interactively
repo property of .pre-commit-config.yaml
can take anything that
git clone ... understands,
it's often useful to point it at a local directory on your
machine while developing hooks and using
pre-commit autoupdate to synchronize changes.
- repo: /home/asottile/workspace/pre-commit-hooks sha: v0.4.2 hooks: - id: trailing-whitespace
Running in migration mode
By default, if you have existing hooks
pre-commit install will install in a migration mode which runs both your existing hooks and hooks for pre-commit. To disable this behavior, simply pass
--overwrite to the
install command. If you decide not to use pre-commit,
pre-commit uninstall will restore your hooks to the state prior to installation.
Temporarily disabling hooks
Not all hooks are perfect so sometimes you may need to skip execution of one or more hooks. pre-commit solves this by querying a
SKIP environment variable. The
SKIP environment variable is a comma separated list of hook ids. This allows you to skip a single hook instead of
--no-verifying the entire commit.
$ SKIP=flake8 git commit -m "foo"
pre-commit during commits
Running hooks on unstaged changes can lead to both false-positives and false-negatives during committing. pre-commit only runs on the staged contents of files by temporarily saving the contents of your files at commit time and stashing the unstaged changes while running hooks.
pre-commit during merges
The biggest gripe we’ve had in the past with pre-commit
hooks was during merge conflict resolution.
When working on very large projects a merge often results in
hundreds of committed files. I shouldn’t need to run
hooks on all of these files that I didn’t even touch!
This often led to running commit with
and allowed introduction of real bugs that hooks could have
pre-commit solves this by only running hooks on files that conflict or were manually edited during conflict resolution. This also includes files which were automatically merged by git. Git isn't perfect and this can often catch implicit conflicts (such as with removed python imports).
pre-commit during push
As of version 0.3.5, pre-commit can be used to manage
pre-push hooks. Simply
pre-commit install --hook-type pre-push.
Confining hooks to run at certain stages
If pre-commit during push has been installed, then all hooks (by default) will be run during the
push stage. Hooks can however be confined to a stage by setting the
stages property in your
stages property is an array and can be set to either
Passing arguments to hooks
Sometimes hooks require arguments to run correctly. You can pass static arguments by specifying the
args property in your
.pre-commit-config.yaml as follows:
- repo: git://github.com/pre-commit/pre-commit-hooks sha: v0.4.2 hooks: - id: flake8 args: [--max-line-length=131]
This will pass
Arguments Pattern in hooks
If you are writing your own custom hook as a
script-type or even a
system hook, your hook should expect to receive the
args value and then a list of staged files.
For example, assuming a
- repo: git://github.com/path/to/your/hook/repo sha: badf00ddeadbeef hooks: - id: my-hook-script-id args: [--myarg1=1, --myarg1=2]
When you next run
pre-commit, your script will be called:
path/to/script-or-system-exe --myarg1=1 --myarg1=2 dir/file1 dir/file2 file3
args property is empty or not defined, your script will be called:
path/to/script-or-system-exe dir/file1 dir/file2 file3
Repository Local Hooks
Repository-local hooks are useful when:
- The scripts are tightly coupled to the repository and it makes sense to distribute the hook scripts with the repository.
- Hooks require state that is only present in a built artifact of your repository (such as your app's virtualenv for pylint)
You can configure repository-local hooks by specifying the
repo as the sentinel
local hooks can be either
local hook must define
files as specified under Creating new hooks
Here's an example configuration with a few
- repo: local hooks: - id: pylint name: pylint entry: python -m pylint.__main__ language: system files: \.py$ - id: check-x name: Check X entry: ./bin/check-x.sh language: script files: \.x$
Overriding Language Version
Sometimes you only want to run the hooks on a specific version of the language. For each language, they default to using the system installed language (So for example if I’m running
python2.6 and a hook specifies
python, pre-commit will run the hook using
python2.6). Sometimes you don’t want the default system installed version so you can override this on a per-hook basis by setting the
- repo: git://github.com/pre-commit/mirrors-scss-lint sha: v0.43.2 hooks: - id: scss-lint language_version: 1.9.3-p484
This tells pre-commit to use
1.9.3-p484 to run the
Valid values for specific languages are listed below:
python: Whatever system installed python interpreters you have. The value of this argument is passed as the
- node: See nodeenv.
- ruby: See ruby-build
Usage in Continuous Integration
pre-commit can also be used as a tool for continuous
integration. For instance, adding
pre-commit run --all-files as a CI step will
ensure everything stays in tip-top shape.
We’re looking to grow the project and get more contributors especially to support more languages/versions. We’d also like to get the hooks.yaml files added to popular linters without maintaining forks / mirrors.
Feel free to submit Bug Reports, Pull Requests, and Feature Requests.
When submitting a pull request, please enable travis-ci for your fork.