How to Use Git Hooks to Move Further Left

The term “Shift Left” is regularly used when discussing feedback loops in DevOps. In essence it means that if one can provide feedback to software engineers in a faster manner, they will have the ability to react faster. Generally, the information that engineers are made aware of are quality issues, build breaks, deployment issues, and hopefully, more often than not, security vulnerabilities.

Most of the feedback generated comes after code is checked into a remote Git repository; usually on a pull request or release workflow. Rarely is an engineer informed of a problem with their code before they commit, unless it’s via an IDE add-in that provides guidance and checks as they code, like GitLens for VS Code. Although these extensions can help engineers learn and fix code as they write it, they don’t provide more complex checks and operations. This is where using Git hooks can help.

Git Hooks are a Collection of Scripts

Git hooks are simply a collection of scripts that get called when engineers interact with the Git executable. As code is committed, merged, pushed, or managed with Git, scripts held within the local code repository are run. An example of this would be running a lint function before code gets committed to a repository.

When a user creates a Git repository on their local machine, a hidden folder is created called .git/hooks, which contains sample scripts that can be modified by engineers. The naming convention for these samples are hooktype-sample. 

Renaming a sample to just its hook type will let Git know that the script should be run. Anything can be put into these files; the possibilities are endless. Unfortunately, there is one major issue here. The .git folder is never committed into a repository, so any changes to the contents of the .git/hooks folder will remain local.

Managing Git Hooks

In order to make management of Git hooks easier and to allow for portability of custom functionality, engineers can utilize a tool called “Hookz” from the DevOps Kung Fu Mafia. 

Hookz is an application that allows engineers to define operations that will be executed for any hook type called by Git in a simple yaml file. This yaml file can be committed to the repository and shared with other repository users. Developers can add custom scripts, calls to executables, and even pull in applications which can be used during hook execution. 

Once this .hookz.yaml file has been created in the root of the local repository and configured with functionality, engineers run the hookz executable which builds all of the scripts needed inside the local .git/hooks folder.

Add Functionality with Git Hooks

Git hooks offer endless possibilities for engineers to add functionality to the Git executable lifecycle. Some examples of functionality that can be added before committing code can be defined for the pre-commit hook type:

• Pulling from the remote repository to ensure there are no upstream changes you’re missing.
• Upgrading all code dependencies to the latest version so upgrades can be tested and incompatibilities addressed – this helps alleviate the accumulation of technical debt.
• Running security tools, namely Software Composition Analysis (SAC) tools that can inform developers of vulnerabilities in their dependencies.
• Executing test cases and generating test coverage metrics.
• Determining the cyclomatic complexity of code, linting, and providing other quality checks.
• Generating Software Bill of Materials.
• Automatically updating markdown documentation (ex: using terraform-docs), or other files.
• Committing anything changed or added during the pre-commit stage back into the commit before pushing to the remote.

If any task fails, a non-zero return code is output from Hookz and the commit will be stopped. This allows developers to address issues before they have a chance to be pushed to the remote repository. 

Git hooks offer a powerful way to tighten feedback loops and get information to the engineer sooner than waiting for tools to be run on the remote repository. This results in cleaner code, quicker fixes, and improved code quality.