Almost all modern VCS (Version Control Systems) provides some kind of hook mechanism. It allows you to define actions which will be triggered when certain events related to your VCS occur. Usually, you will be able to attach a hook at least before and after the commit and before and after the push. GIT for example allows you to trigger hook before and after dozens of specific events. The mechanism is very useful for automatic verification of any changes reaching the repository.
Hooks can generally be divided into two categories: executed locally and remotely on a VCS server. Both have their advantages and disadvantages. One of the major drawbacks of local hooks is that they can usually be easily disabled by a developer. If you are obliged by your organization to always conform to some rules you can not use it. However, if you are not and you are quite sure that developers will not intentionally (until they have valid reasons) disable them you should follow this path. Local hooks lower the load on the remote repository server (especially when you have complicated checks) and provides commit feedback to developers much faster. It is not fun at all when you need to wait 5 minutes to know if your commit passes all rules. However, you will have to implement a mechanism for automatic updates of all hooks on developer machines. In case of a centralized hook there is no need for that.
There are several kinds of hooks that are worth implementing no matter what your project is about and what technology and frameworks it uses:
- hook verifying if the commit message contains a valid identifier of corresponding to change task in the issue tracking system. Thanks to it you can always check the issue that is related to the commit. While of course some discipline is required (do not commit for weeks on the same issue) it greatly facilitates changes tracking. This is one of the hooks that is advised to implement in a central repository. It is quite fast and it would be great if it would integrate with issue tracking system to verify task existence and correctness,
- check for any bad practices and prohibited behaviour. One of the most obvious examples is hook rejecting force push which would effectively make problems for everybody else using the same repository. Another example is verifying if the merge of remote changes was done by rebase and if unnecessary branches which tangles history are introduced. You can also enforce a rule that no one is able to push changes after 5 p.m. so that it is almost ensured that night builds will be successful,
- check for obvious compilation errors, not valid xml and json files, etc. Instead it is to be checked by CI build, you can use such a hook to filter out the most obvious mistakes at the commit phase. It is especially useful in larger projects where builds are quite time consuming and provides feedback in hours,
- committed and pushed files size verification. As distributed VCS stores almost all committed files forever, adding large ones can decrease repository performance significantly. Hook mechanism is a nice place to prevent it from happening,
- hook triggering push notifications. Any systems based on VCS can, instead of pulling regularly changes, wait for push notifications. It is not only more effective but also decreases time from your push to CI build results. It is also a great way of notifying the team or your project leader that new changes are available.
If you are working with legacy code and projects, hooks checking code quality introduces some kind of turmoil. It is not a rare case that only a few lines of few thousands lines class (which has hundreds of quality violations) are modified. As a result, hook will block commit and output all violations. Incremental hook implementation verifying only modified lines is a time consuming task and introduces several hard to solve problems. If your project is not a large one, in my opinion it is better to check only new classes for code quality and ensure that proper reviews are done.
Nevertheless, experiment with your project. Check if and what manual steps are performed around publishing your changes. Brainstorm a little bit with your team and figure out what is worth adding to hooks. Search for bad practices and for what bothers your team and check if it can be prevented at the commit and push stages.
VCS hooks are a nice tool helping developers to provide high quality commits and code. While there is sometimes some resistance on this matter, programmers usually get used to them quite fast and cannot imagine working without their protection. When hooks would break and some commits with an improper message would pass they would be amazed and ask: why that happened, hooks should filter it out! If you are not using hooks in your project, setup the simplest ones as fast as possible. The most popular ones are available for free. A few hours of effort would pay off for sure!