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…
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.
- 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).
- 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