Using Git Hooks to Support Configuration Management

Git Hooks are an interesting and powerful feature built in to any git repository that allow you to run scripts when certain commands are executed. These allow you to “hook in” to the git lifecycle, which makes them quite useful when trying to keep things organized and preventing common errors.

Teams should always have clearly defined practices and standards in place for their developers to ensure things stay in check. These practices can include things like making sure commit messages reference a tracked issue, preventing pushes to certain branches or making branches follow descriptive naming patterns. While developers should have these things in mind when working, tooling can greatly reduce or even stop the number of errors made.

Git provides a wide variety of hooks, but the most common are the following:

• pre-commit
• prepare-commit-msg
• commit-msg
• post-commit
• post-checkout
• pre-rebase

They’re pretty self-explaining. Basically, pre-commit runs right before a commit is made, prepare-commit-msg modifies the commit message, commit-msg checks the commit message, so on so forth. Let’s take a look at some examples of what can be done.

Issue tracking

According to software configuration management guidelines, all changes to be made need to be documented and approved via a software change request. These change requests should point to issues tracked in some tool like Jira, GitHub Issues or something similar. As these issues are given unique identifiers, commit messages can be used to track as the change gets implemented in the code base and what branches it’s on. Hooks can be leveraged to support this measure in a variety of ways. The commit-msg hook could be used to verify that a correctly-formatted issue number is included in the message. Furthermore, this number could be checked against a service for validity.

Automated Testing

When developing using methods like Test Driven Development (TDD), unit tests are absolutely required. Even if a TDD strategy is not being used, all unit tests must pass before committing or pushing to ensure bad code never even gets to the server. You could use hooks to ensure that tests are run and block pushes that introduce changes that don’t pass tests.

Small, Frequent Commits

There are many reasons why you may want commits to be kept small. Small and frequent commits help code changes be better documented, prevent merge conflicts caused by changing too much at once and allows you to track when bugs were introduced more easily, among others. Hooks can be created to ensure the amount of files or modules touched remains under a certain range.

Continuous Deployment

When changes are merged to specific branches, hooks can be created that automatically deploy a new version of the software to staging or testing servers, greatly reducing user error by removing that manual deploy step.

Limitations

As you can see, hooks can be used for a variety of things and their ability to execute any script makes them really flexible and powerful. However, while these hooks can be used to help the user abide by certain practices, they are not a way to enforce them. While there are some hooks that run server-side, all the hooks mentioned here run on the client. This means that you can’t rely on them completely, since they can be altered or completely disregarded by each user should they choose to do so.

Of course, there can be a policy that requires the team to use these hooks, but you can never trust something client side will be enforced. If these things need to be absolutely followed and can’t be left to the user, checks need to be put in place on the server side as well as in the process of accepting changes that have been made.

Furthermore, hooks live in the hidden, untracked /.git directory of a local repository, which means making all developers use the hooks isn’t as easy as just cloning the project and getting all the hooks set up. This would require extra configuration, possibly setting up a symlink to a file that is tracked on the repository.

Most git platforms like GitLab and GitHub provide features that assimilate certain hooks, but run on the server side and do not depend on a client. GitLab’s Pipelines and GitHub’s recently introduced Actions allow you to automate your workflow by allowing you to define tracked scripts that get executed on the server-side. On the other hand, using either platform’s built-in issues solution allows you to reference commits and issues and implement things like automatically closing tasks with ease.

—

Git Hooks are a powerful feature that can help developers follow guidelines and best practices before (and after) their code is even pushed. It lends itself to some pretty interesting and useful applications, but they should not be relied on to absolutely enforce hard rules and execute critical validations. These should be complemented by CI/CD tools like those included in most git providers in order to fully cover all needs.

For more information on hooks, including all hooks I did not mention in this article, check out https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks.

This article was written as part of a Configuration Management class at INTEC University.