← Back to list

Saving Reviewers from Code Headaches: How Git Pre-Commit Hooks Can Be Your First Line of Defense

It’s Friday evening. You just finished a massive feature, ran it locally, and everything “seems fine.” You push the code, open a PR… and…

Salman Ali Khan · 2025-08-09 19:05 · 1 claps · 2.8 min read
#code-quality #shift-left-approach #git #coding-best-practices #software-engineering
Open on Medium ↗
Wiki topics: PFI · Personal Finance 💻 · Programming 🔓 · Open Source

Saving Reviewers from Code Headaches: How Git Pre-Commit Hooks Can Be Your First Line of Defense

It’s Friday evening. You just finished a massive feature, ran it locally, and everything “seems fine.” You push the code, open a PR… and the reviewer’s comments start rolling in:

  • “Can you fix the indentation here?”
  • “Why is this variable unused?”
  • “This method has a cyclomatic complexity of 18. Can we refactor?”

By the end, your PR looks like a mini-warzone of red and green lines — not because your logic was wrong, but because of small code quality issues that could have been caught earlier.

That’s where Git pre-commit hooks come in. Think of them as your personal quality gatekeeper, running checks before your code even leaves your machine. They save time for you, for reviewers, and for your CI/CD pipeline.

What is a Git Pre-Commit Hook?

A pre-commit hook is a script that runs right before a commit is made. It can:

  • Run linters
  • Format code
  • Run unit tests
  • Block commits if checks fail

This means your repo stays cleaner, your PRs are smaller, and your team spends more time reviewing logic instead of whitespace.

Example: Integrating SonarLint for .NET 8

Let’s say you have a .NET 8 backend API. You want to make sure every commit passes SonarLint analysis locally before it even hits the repo.

  1. Install SonarLint in Visual Studio
  • Go to Extensions → Manage Extensions
  • Search for “SonarLint” and install it
  • Connect it to your SonarQube or SonarCloud server (optional but recommended for team rules)

1. Add a Pre-Commit Hook Script

Inside your .git/hooks/pre-commit file (create it if it doesn’t exist):

#!/bin/sh
echo "🔍 Running SonarLint for .NET 8..."
dotnet build /warnaserror
if [ $? -ne 0 ]; then
  echo "❌ Code quality check failed. Please fix issues before committing."
  exit 1
fi

2. Make the Hook Executable

chmod +x .git/hooks/pre-commit

Now, any build warnings (e.g., SonarLint issues) will fail the commit instantly.

Example: Integrating ESLint for Angular Frontend

Angular projects often come with ESLint pre-installed (or can be added with ng add @angular-eslint/schematics).

  1. Install ESLint
npm install eslint @angular-eslint/schematics --save-dev

2. Add ESLint Configuration (.eslintrc.json)

{
  "extends": ["plugin:@angular-eslint/recommended"],
  "rules": {
    "quotes": ["error", "single"],
    "semi": ["error", "always"]
  }
}

3. Create Pre-Commit Hook

If you want something more maintainable than manually editing .git/hooks, use Husky:

npm install husky --save-dev
npx husky install
npx husky add .husky/pre-commit "npm run lint"
git add .husky/pre-commit

In package.json:

"scripts": {
  "lint": "eslint . --ext .ts"
}

Now, any linting errors will block the commit:

$ git commit -m "Add new feature"
🔍 Running ESLint...
/src/app/app.component.ts
  2:10  error  'name' is assigned a value but never used  @typescript-eslint/no-unused-vars
❌ Commit aborted.

Combining Backend & Frontend Checks in One Hook

If your repo has both .NET and Angular, you can combine them:

#!/bin/sh
echo "🔍 Running SonarLint (.NET 8)"
dotnet build /warnaserror
if [ $? -ne 0 ]; then
  echo "❌ .NET code quality check failed."
  exit 1
fi
echo "🔍 Running ESLint (Angular)"
cd frontend || exit 1
npm run lint
if [ $? -ne 0 ]; then
  echo "❌ Angular lint check failed."
  exit 1
fi
cd ..

Why Reviewers Will Love You for This

  • Fewer nitpicks — Reviewers can focus on logic instead of spacing.
  • Faster merges — No “fix lint” commits after every PR.
  • Consistent style — Your codebase feels like it’s written by a single developer.
  • Early bug detection — SonarLint and ESLint can catch potential runtime issues.

📌 Final Tip

Don’t treat pre-commit hooks as “just another blocker.” Treat them like a personal guardrail. The 5 seconds they take can save hours in review and bug fixing.

Also, Pair this with a .editorconfig file at the root so IDEs use the same formatting rules. That way dotnet format and eslint aren’t fighting with your edit.

Next time your PR sails through review without a single formatting or lint comment, you’ll know your pre-commit hook is quietly doing its job.


메타데이터
post_id
5d51d79c8cc1
slug
saving-reviewers-from-code-headaches-how-git-pre-commit-hooks-can-be-your-first-line-of-defense-5d51d79c8cc1
url
https://medium.com/@salmanalikhan17/saving-reviewers-from-code-headaches-how-git-pre-commit-hooks-can-be-your-first-line-of-defense-5d51d79c8cc1
canonical_url
https://medium.com/@salmanalikhan17/saving-reviewers-from-code-headaches-how-git-pre-commit-hooks-can-be-your-first-line-of-defense-5d51d79c8cc1
author_url
https://medium.com/@salmanalikhan17
status
ok
fetched_at
2026-07-19 16:25:04