If you are a very careful person you might proof read your diffs before committing. While I generally follow this advice it can be quite easy to miss something, like a
binding.pry you were using to debug/test your changes. You’ll probably catch this before you deploy.
If you don’t though…
Well, let’s just avoid those potentially devastating timeouts in prod by utilizing a pre-commit hook. For those unaware, git hooks are a mechanism available to git users which executes scripts when “certain important actions occur” within your git repository. One of these important actions is commiting. Git provides several hooks around this action, one of which is the aforementioned pre-commit hook.
This is just a simple (and suboptimal) shell script that when run at the root of a Rails project will attempt to use git’s grep to find instances of
binding.pry in your source. If one is found it exits non-zero which indicates to git that the in-progress commit should be cancelled! Mistake avoided!
If you have pre-commit hook returning a false positive (returning non-zero when it should not be) you may always bypass a failing pre-commit hook by adding a
-n for lazy users) to your commit command.
You may have noticed that the above script does not simply check for
debugger. It also checks for diff artifacts (i.e.
=======). These are just two things you may want in your precommit hook. Perhaps, you want to avoid committing invocations of
To install this hook you’ll have to do something like the following.
curl https://gist.github.com/RyanMcG/5775028/raw/rails-pre-commit chmod +x rails-pre-commit mv rails-pre-commit path/to/your/rails/root/.git/hooks/pre-commit
Complex hooks often develop over time. When they do, modularity can simplify creating and sharing new part. While git does not help with this out of the box there are various projects which do.
One such project, aptly named git-hooks, allows many scripts to be specifies for the same action. It uses subdirectories with the same name as the the hook inside of a folder called
git_hooks at the root of the repository. Source controlling the hooks is often desirable so you can share them with the rest of your team.