Git: pre-receive hook with PHP_CodeSniffer

Question

Since switching from SVN to Git, we lost the ability to enforce our coding standards through a pre-commit hook on the subversion server.

With Git, you only

Answer 1

use jenkins + gerrit:

http://alblue.bandlem.com/2011/02/gerrit-git-review-with-jenkins-ci.html

if your build fails, the push will be rejected.

http://source.android.com/source/life-of-a-patch.html

Tyrael

Answer 2

I used this hook: http://criticallog.thornet.net/2011/06/02/running-php-linter-before-pushing-changes-to-a-git-repository/

and modified it to also test code with phpcs.

Might contain some bugs and I have hardcoded drupal code standard but it works! http://pastebin.com/fEmN519B

Answer 3

I don't think there's a technical solution here but if you really want to bother people, then integrate phpcs into your CI setup and start opening tickets for it in your issue manager. ;-)

I don't think that's the best idea though because it's really not a technical problem. Your issue is not a pre- or post-commit hook, but that people don't do it and you think you have to force them.

All in all, I understand the importance of a coding standard and I enforce one as well, but there's a social component (or aspect) to it.

It sounds like the people working with you either don't know any better (yet) or are un-willing to learn. So, in case they don't know any better you have to work with them and teach them to adhere to your requirements. That includes teaching them why conventions are important and in the end they need to understand that a feature is not done until everything is green.

Maybe that requires that project management (I gather that's you) breaks down an issue into multiple tasks until they get it:

• feature itself
• phpcs
• documentation
• unit-tests

(In no specific order. ;-))

If they're unwilling to learn you can always take more drastic measure. Like, I'd start off slowly and do a weekly performance review (1-on-1 situation) and reiterate why they don't do it. If that doesn't help -- I guess you catch my drift.

Answer 4

I don't have an exact answer to this question directly using pre-commit/pre-recieve hooks etc.

I approach this from the other way, running a CI server, (I use jenkins) running phpcs and the checkstyle plug-in for Jenkins.

This allows me to fail the build and email the committer based on the checkstyle report.

Optionally I can set thresholds, so I get an unstable build if there are upto 5 new style violaions but a failure if more than 5 are committed.

Also I can set overall thresholds, so more than 10 violations in the whole project causes a failure and emails the team.

This could be your intermediate server as mentioned above. The post build actions can include a Push to another git repo.

Answer 5

We use a git wrapper (to replace git-submodules with something more sane for our purposes) and it has the side-effect of automatically setting up pre-commit hooks automatically from a magic directory. Since this is in a business environment, there are no complains (and there is a way to turn that off anyway).

Answer 6

We do now employ pre-commit hooks that both check the code and the commit message.

Developers can skip them with -n, but they rarely do and we always have another developer doing QA so things get noticed.

The hook is important because it notices when files are broken, so that broken PHP or JS doesn't get committed at all.

Find them hook code at https://github.com/netresearch/git-client-hooks

We use a central server for development, and our git hooks get automatically installed because we provide a central git repository template that gets used automatically when you git clone or git init.