A 5 minute talk about what commit hooks generally are, and several things you can use them for.

1. You're Doing it Wrong:
Commit Hooks!
or
Commit Hooks: the Subtle Hammer
Ben McGraw
Sr. Software Engineer, IMVU Inc.
ben@imvu.com
@bengrue

2. What are commit hooks?
A way to run automated actions before your local changes get
committed to your code repository.

3. What are commit hooks?
A way to run automated actions before your local changes get
committed to your code repository.
A way to make the computer check all those annoying little
repetitive tasks before your code goes on your permanent
record.

4. Computers are good at repetition.
(People are bad at repetition...
and good about forgetting little things!)
Make the computer do the repetitive,
boring stuff so you can focus on the
interesting code.

5. How do I make them?
In SVN:
as the SVN user, go to /PATH_TO_REPO/hooks/ and make an
executable script file in your favorite shell scripting language.
In GIT:
Basically the same... but there's a lot more options/specific
hooks available (see link at the end).

6. How do I make them?
The basic principle is the same in both:
1. The script receives text about the files you're attempting to
commit.
2. You inspect those files for rules you make yourself.
3. If you want the commit to not get through to the repository,
return an error code (and print out an error message to
STDERR).
4. Otherwise, your commit continues on to the repository.

7. Best Practices
1. Subdivide each individual check into it's own function.
2. Give each individual check it's own passphrase to skip it.

8. What can you use them to do?

9. Enforce Coding Conventions
- Prevent Code that doesn't allow Linting (Static Analysis!)
- Enforcing Company/Project-specific coding style guidelines
- For example, IMVU has commit hooks to prevent:
- tabs from being committed
- leading-underscored ('lazy private') functions from being
used outside of a module.
- using a module's name in a function
(e.g., customer::get() is good,
customer::get_customer() is bad.)
- Passphrase to skip is per type ("Skip whitespace check.",
"Skip module check.", etc... )

10. Running tests as part of your workflow
- One of the simplest way to integrate test-running into a coding
workflow
- If you want acceptance tests, and you don't prevent commits
upon failure, you're Doing It Wrong (but that's a seperate talk).
- Running tests-pre commit doesn't scale to a large team / large
number of tests

11. Continuous Deployment?
- If you're doing a Continuous Deployment System, commit
hooks are a simple but critical element of your system...
If your build system is red, you must prevent commits.
- Passphrase to commit through this:
"Fixing buildbot"

12. Locking Down Sensitive Areas
- Some areas of your architechture are incredibly sensitive (e.
g., low-level database/memcache libraries, payment
processing, )
- Try to use this sparingly (make a blanklist of files, not a
whitelist) since it breaks workflow and halts engineer velocity to
have to verify everything on every file.
- Passphrase to commit through this:
"Reviewed by XXX" where XXX is the name of an engineer.

13. Enforcing Social Policies
- You can enforce a Code Freeze during weekends and
holidays to prevent committing to the main code line when
there's minimal staff around.
- Lowers stress for ops during off-hours
- Engineers can commit to branches during the weekend to
work unimpeded

14. Enforcing Social Policies
- We found this useful at IMVU for years, but refinement of our
entire Continuous Deployment system has recently made us
reconsider preventing weekend commits, so we changed policy!
- Passphrase to commit on weekends is a password that is listed on
the internal wiki for the weekend commit policy. The passphrase is
changed every time we change the policy.
- The rejection error message itself contains the link to the wiki
page with the current policy and the passphrase.

15. The Shibboleth of Saving Face
Problem:
Sometimes you are proving something to yourself in your
sandbox (noodling through a problem) and you don't want this
code going out.
Sometimes you forget and commit that code.
Solution:
A commit hook checking for the phrase "DO NOT COMMIT".
Now when you noodle, you start it with that phrase in a
comment and your ass is covered.
Override: "Ignore Do Not Commit"

16. Passive Education
Not strictly "coding conventions" in the traditional sense, but
good habits based on context.
For example:
$_REQUEST bad in PHP, $_GET/$_POST are good...
...so forbid access of $_REQUEST and link to a webpage that
explains why, and provide a short blurb of how to correct the
issue.
For these types of rules, no specific "skip this" message

17. Further reading (yay homework)
- http://wordaligned.org/articles/a-subversion-pre-commit-hook
General how-to for SVN pre-commit hooks
- http://book.git-scm.com/5_git_hooks.html
General how-to for all sorts of GIT commit hooks
- http://eng.wealthfront.com/2011/03/corrective-action-with-gits-
pre-commit.html
Corrective Actions with GIT commit hooks
- http://engineering.imvu.com/
We do cool things, and talk about workflow/build systems a lot

18. Questions?
Ben McGraw - @bengrue