Last month, in the PHP Barcelona Monthly Talk, I was talking with some mates about the GitHub migration we have recently done at Atrápalo. They were interested in branches, deployments, code reviews and so on. However, they were specially surprised about who we are dealing with pre-commit hooks at Atrápalo. Let’s see if there’s more people out there interested in the subject.

Checks in our pre-commit hook

At Atrápalo, each time a developer wants to commit its code, we run several checks:

1. Syntax check with php lint (“php -l”): We check every committed file has a valid PHP syntax.
2. Sync check of composer.json and composer.lock files: We check these two files are committed together in order to avoid committing the json but not the lock and generate some issue to another developers.
3. PHP CS Fixer check: With the –dry-run parameter it does not fix, just say what the problems are. With the –fixers parameter you can control what fixers you want to execute.
4. PHP Code Sniffer check: Same as before, but another rule that checks another rules.
5. PHPMD: We have enabled the controversial rules.
6. Unit Testing check: We run around 3.000 tests right now.

Maybe you think it’s too much, and it is, however it takes about seconds (specially if your tests are fast) and it mainly guarantees that you don’t break the unit tests and the code is formatted based in your coding standard. Check Coding Standard, TDD and Continuous Integration as XP related practices.

Keeping our hooks under git control

In any Git project, you have a .git folder. Inside, there is another hooks folder where hooks scripts samples can be found. For more info, visit [git hooks reference][1]. For making a hook work, just remove the .sample extension from a file and done.

[][2]

At Atrápalo, we have a doc/hooks folder with two files:

Both are plain files, so managed without any problem with git.

[][3]

So, what’s the silliest idea to link these two folders? Yep! a soft link!

When a developer clones the project, it just needs to:

Remembering to set up the hooks

If you want to remember you developers to do the trick, add a Composer script to remember it.

You could make the script create the hooks, however, I’m trying first to be polite about it. For more information about how to create scripts in Composer visit its reference.

pre-commit hook in PHP

An easy way to develop your hooks is in PHP, you have set up everything, so carry on with PHP. Following there is an example. The most interesting part is that we are using Symfony Console Component as the Application, each library comes from composers (phpunit, phpmd, php-cs-fixer, etc.) and we are running all the command using the Symfony Process Component.

So that’s it! That was easy and useful. Hope it helps someone out there. If there’s people doing something different or better, please share to improve it.

Update:

If you want to directly set up your hooks when executing “composer install” or “composer update”, you can just add the bash lines to do so in the “scripts” section of your composer.json file. See an example:

• code sniffer
• git
• hook
• php
• php-cs-fixer
• phpunit
• precommit