Automate Your Git Workflow: Validate Commits Like a Pro

Last year, I wrote a post called “Commit with Confidence: Naming Conventions for Git”, which laid out some guidelines for writing clear, consistent commit messages. I even included an Example Naming Scheme that showed how to structure commit titles based on task type. Typically, the format is:

<type>: <short blurb>

…with more detailed information provided in the commit description.

While these guidelines are useful, let’s be honest, it’s not always easy to remember them. And the last thing anyone wants to do when committing at 4:00 AM is dig through a separate document for reference.

Luckily, implementing these practices doesn’t have to be difficult. We can automate them using Git hooks.

What are Git Hooks?

Git hooks are scripts that Git executes before or after certain events, such as committing, merging, or pushing. They allow you to enforce rules, validate code, or automate tasks directly in your workflow.

One hook of particular interest for commit message enforcement is the commit-msg hook. This hook runs every time a commit is created, letting us validate the message format automatically, right from our IDE.

1. Configure your IDE to use GitBash

Before we can create the commit message hook, we need to ensure that we are using GitBash for the Terminal in Rider.

1. Go to File > Settings > Terminal
2. Set the Shell Path to GitBash
3. Save your settings

2: Create the commit-msg hook

1. Open the terminal in your project and navigate to the hidden .git/hooks folder:

cd .git/hooks

2. You’ll notice several sample hook files, including commit-msg.sample. We’ll keep this for reference and create our own:

touch commit-msg

3. Make the file executable:

chmod +x commit-msg

4. Open the commit-msg file in your editor and add the following:

#!/bin/sh

echo "commit-msg hook ran"

5. Save the file.

3: Test the hook

1. Create a new test file in your project to simulate a change.
2. Stage the file and open the commit window.
3. Type any commit message and press Commit.
4. In the Git console, you should see:

commit-msg hook ran

Huzzah 🎉! The hook is working, but right now it doesn’t enforce any rules.

4: Enforce commit message rules

Using the guidelines from my previous post, we can make the commit-msg hook validate commit messages:

#!/bin/sh

#echo "commit-msg hook ran"

# COMMIT_MSG_FILE points to the temporary file containing the commit message
COMMIT_MSG_FILE=$1
COMMIT_MSG=$(head -n 1 "$COMMIT_MSG_FILE")

# Allowed commit types
TYPES="init|feat|fix|docs|refactor|test|chore|opt|build|revert|hotfix"

# Regex: type: short description
PATTERN="^($TYPES): .+"

if ! echo "$COMMIT_MSG" | grep -Eq "$PATTERN"; then
  echo ""
  echo "❌ Invalid commit message format."
  echo ""
  echo "Expected format:"
  echo "  <type>: <short description>"
  echo ""
  echo "Allowed types:"
  echo "  init, feat, fix, docs, refactor, test, chore, opt, build, revert, hotfix"
  echo ""
  echo "Examples:"
  echo "  feat: add health regeneration system"
  echo "  fix: resolve null reference in player controller"
  echo "  docs: update README with setup instructions"
  echo ""
  echo "Optional:"
  echo "  Add a blank line and a detailed body after the title."
  echo ""
  exit 1
fi

exit 0

5: Test the validation

1. Make a change to your test file.
2. Try to commit with a message like:

It works

3. In the Git console, you’ll see an error explaining that your commit message is invalid and showing the correct format along with allowed types.3

4. Now, rewrite the message following the rules:

test: testing commit-msg validation

5. Commit again; this time it should succeed with no errors.

6. Customize as needed

The commit-msg file can be updated anytime to:

• Add additional allowed types
• Adjust formatting rules
• Include more detailed validation

Summary

Enforcing consistent commit messages doesn’t have to be a chore. By leveraging Git’s commit-msg hook, you can automatically validate commit messages against your team’s standards, right from your IDE.

This approach:

• Reduces errors by catching poorly formatted commits before they enter the repository.
• Saves time by eliminating the need to constantly reference external documentation.
• Is flexible, allowing you to add new commit types or formatting rules as your workflow evolves.

With just a few lines of shell script, you turn best practices into a seamless part of your development workflow—so you can focus on coding, not remembering the rules.

Remember: commit confidently, commit consistently, and let Git do the enforcement for you!