Git: pre-receive hook with PHP_CodeSniffer

I would rather not wait for a server-side hook to control a push.

You could setup an intermediate repo which would fetch each developer's branches very regularly and audit each new commit, sending an email if a commit fails to meet some pre-defined criteria.

You can also have pre-receive hook on the central repo, but at least the developer would be aware of a potential issue sooner.

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.

In the Drupal project, we've recently migrated to Git and are looking at similar problems. In our case, we don't want anyone checking in a LICENSE.txt file for a module since our packaging scripts do that automatically. After some back and forth, what we came up with was a receive hook that doesn't reject a bad commit, but every time it detects a bad commit (for some definition of "bad") it automatically files a critical bug in our bug tracker. That way the code is still committed, but the module maintainer and the appropriate webmaster team both get notified immediately that something is amiss and should be fixed. You could just as easily send an email or send a tweet or whatever other notification you want.

Actually we haven't implemented that quite yet, but that's the plan we're working on as soon as our Git implementation team has time. :-)

Basically, there is no good solution for the problem you describe other than rephrasing it; instead of "block detectable violations" it becomes "report detectable violations." I think that's the best you can do.