Git Pre-Commit — Part 1 — Zero Trust My Code!

In today’s article, we will be chitchatting about the “Git pre-commit” and the “Pre-Commit framework”. One can use these tools to keep the codebase tidy and catch mistakes/issues before things get worse and committed into Git.

It happens that you onboarded a new team member who is still not that familiar with the internal culture, or you just made a typo and shirked to run your code linter! At the time, you don’t really notice; You merely go ahead with your modifications and commit code. Then, either something breaks or just the quality of the code base has gone down just a little bit. :(

Well, a bad config you can fix, and code you can just reformat!….. But!!

But still, wouldn’t it be better if one could catch those errors early and have the code well-cooked before the commit happens? That’s what pre-commit it is for.

Automate Code Cooking

Fix your Mistakes, Don’t Commit them!!

Basically, Git has a notion of what is called Commit hooks. These are things that happen either before committing (pushing, pulling, etc.) code or after that.

Let’s dive into it.

Today’s Menu!

What are we covering today? Well, everything is separated into two distinct parts. Please feel free to jump right to the section that you feel impacts you.

Part1: Introducing Git-Hooks
  - How Does it work?
  - How to get Git pre-commit hooks configured?
  - Grab&Go - Quick Lab!
Part2: The Pre-Commit Framework
  - How to get it configured?
  - Pre-Commit - Checkov
  - Pre-Commit - Caching Mechanisms
Pre-Commit - Team Collaboration!
To Conclude

Part 1 — Introducing Git-Hooks

Git hooks, in a nutshell, are custom scripts or logic that trigger when one performs a specific action in Git. They are used to automate tasks before (pre-) or after (post-) a Git command is executed.

Example: You can abort a `commit` if the message doesn’t start with an IssueID, or when the code analysis or linting fails.

Hooks run automatically when specific events such as Committing, Merging, or Pushing code occur to approve or reject an action.

How Does it work?

Every Git repository, when initialized, gets its own .git/hooks folder that may include samples for each possible hook. The folder can be freely altered with a set of desired executables to be run when an event occurs.

Note: Pre-commits hooks are also executed on Pull-Requests or Merge-Requests.

How to get Git hooks configured?

Well, whenever a Git repository is cloned/initialized, all the Git data for the project are generated/stored in.git within the project folder. The .git folder contains several files and sub-directories, one of which is called hooks. Inside, there are a bunch of built-in samples.

# Initialize a Git working dir:
git init
# List the content of .git/hooks folder:
ls -al .git/hooks

Built-in Hooks are stored in `.git/hooks/` folder.

Each of them is a script, which is executed once a specific event occurs. The event name matches the file name.

As an example, the script ./git/hooks/pre-commit is triggered by a git commmitcommand and is conducted before committing code.

Files having the extension .sample are ignored by Git, unless renamed to match an event name. You can find short descriptions and sample implementation inside the sample files, which can be a good starting point when implementing custom hooks.

Git Hooks — Git Pre-Commit

The Git Pre-Commit operation happens in an earlier phase before having the code committed to Source Control, as shown below:

Pre-commit hook stage

Grab&Go — Quick Lab!

Three easy steps are required to experience a Git Hook.

1. Initialize a folder and choose a hook to implement/copy; We will stick to the “pre-commit hook” in this quick example.

mkdir built-in-hooks; cd built-in-hooks
git init
echo "Some text" > README.md
# Enforce an empty email (For hook testing purposes only)
git config user.email ""

2. Copy & Paste the script content below to the file .git/hooks/pre-commit. The script references a pre-commit hook type and verifies whether an email is configured before having the code committed.

#!/bin/bash
PWD=`pwd`
if [ "$(git config user.email)" == "" ]
then
  echo "Error: email is not configured!";
  echo "run:"
  echo '   git config user.email "your@email.com"'
  echo ''
  exit 1
fi

Apply Execute permissions on the file:

chmod +x .git/hooks/pre-commit

3. Execute a git add . So, the files are known and tracked by Git.

4. Execute a git commit -m “init” to trigger pre-commit checks. Observe the automated checks.

That looks great, Isn’t it?

But, This is not how we are going to do it today!

To Conclude

Such tools are so beneficial even though they can be irritating to developers. Cases can be when having hooks that fail Git operations with mysterious messages or ones that make a long-winded scan on every commit.

Part 2 of Git-Commits is already available.