In today’s fast-paced software delivery landscape, maintaining code quality while shipping faster is one of the biggest challenges engineering teams faces. As applications grow in complexity and teams scale across geographies, even small inconsistencies — like poorly formatted code, missing tests, or accidental exposure of secrets — can lead to significant production issues.

This is where Git Hooks emerge as a powerful yet often underutilized capability.

Git Hooks are lightweight scripts that run automatically at specific points in your development workflow such as before a commit or push, allowing you to enforce rules, automate checks, and prevent errors before they propagate downstream. Instead of relying on manual discipline or catching issues late in CI/CD pipelines, Git Hooks enable a shift-left approach, ensuring that quality, security, and consistency are embedded right at the developer’s workstation.

In this comprehensive guide, we will go beyond just “what Git Hooks are.” You’ll learn how they work, how to implement them effectively, and how to leverage them in real-world DevOps scenarios — including CI/CD integration, DevSecOps practices, and workflow optimization.

What Are Git Hooks?

Git Hooks are scripts that automatically run at specific points in the lifecycle of a Git operation. These scripts are triggered by events such as committing code, pushing changes, or merging branches.

They are a built-in feature of Git and exist inside every repository.

Location

Git Hooks are stored in:

.git/hooks/

Inside this directory, you’ll find sample scripts like:

• pre-commit.sample

• pre-push.sample

• commit-msg.sample

To activate a hook, you are simply:

1. Rename it (remove .sample)

2. Add your logic

3. Make it executable

Why Git Hooks Matter in DevOps

Git Hooks act as guardrails for your development workflow. Instead of relying on developers to manually follow best practices, hooks enforce them automatically.

Key Benefits:

• Enforce code quality standards

• Prevent bad commits

• Automate repetitive tasks

• Improve CI/CD reliability

• Shift validation left (early feedback)

In DevOps culture, where automation is everything, Git Hooks provide a lightweight yet powerful way to reduce friction and errors.

Types of Git Hooks

Git Hooks are broadly divided into two categories:

1. Client-Side Hooks: These run on the developer’s local machine.

Common Client-Side Hooks:

Example Use Cases:

• Run linting before commit

• Validate commit message format

• Prevent committing sensitive data

2. Server-Side Hooks

These run on the remote repository server.

Common Server-Side Hooks:

Example Use Cases:

• Enforce branch protection

• Trigger CI/CD pipelines

• Validate code at organization level

  

Let’s break down what happens when a Git Hook is triggered:

Example: pre-commit Hook

1. Developer runs:

git commit -m "Added feature"

2. Git triggers the pre-commit hook

3. Hook script executes:

• Runs linting

• Runs tests

• Checks formatting

4. Script returns:

• 0 → Success → Commit proceeds

• Non-zero → Failure → Commit blocked

Execution Flow

Developer Action → Hook Triggered → Script Runs → Exit Code → Continue/Stop

This simple mechanism gives you immense control over your workflow.

Let’s create a basic pre-commit hook.

Step 1: Navigate to Hooks Directory

cd .git/hooks

Step 2: Create Hook File

touch pre-commit

Step 3: Add Script

#!/bin/sh
echo "Running pre-commit checks..."

Step 4: Make Executable

chmod +x pre-commit

Step 5: Test It

Now try committing:

git commit -m "Test commit"

You’ll see:

Running pre-commit checks...

Let’s explore a practical scenario.

1. Code Quality Enforcement

Before code even enters your repository, you can enforce standards.

Example:

• Run ESLint / Flake8

• Check formatting

npm run lint

Result:

• No more messy or inconsistent code

• Clean, maintainable repositories

2. Prevent Secrets from Being Committed

One of the biggest risks in development is accidentally committing sensitive data.

Example:

• AWS keys

• API tokens

• Passwords

Using a pre-commit hook:

if grep -r "AWS_SECRET".; then
  echo "❌ Secret detected!"
  exit 1
fi

Result:

• Prevent security breaches early

• Strengthen DevSecOps practices

3. Automated Testing Before Push

Instead of waiting for CI to fail, catch issues early.

npm test

Result:

• Faster feedback loop

• Reduced pipeline failures

4. Commit Message Validation

Standardizing commit messages improves collaboration and release automation.

Example:

Enforce Conventional Commits:

feat: add login API
fix: resolve bug in payment

if! grep -qE "^(feat|fix|docs):" "$1"; then
  echo "Invalid commit message!"
  exit 1
fi

5. Trigger Deployments or Notifications

Server-side hooks can:

• Trigger Jenkins pipelines

• Deploy applications

• Send Slack alerts

Result:

• Fully automated workflows

• Faster releases

Git Hooks in CI/CD Pipelines

Code Write → Git Hooks → Push → CI Pipeline → Build → Test → Deploy (Pre-checks)

How They Fit:

Shift-Left Strategy

Git Hooks enable:

• Early validation

• Faster debugging

• Reduced CI load

Instead of catching errors later, you prevent them at the source.

Best Practices for Git Hooks

1. Keep Hooks Fast

Slow hooks frustrate developers.

Tip:

• Run only essential checks

• Avoid heavy operations

2. Share Hooks Across Teams

Problem: Hooks are not version-controlled by default.

Solution:

• Store hooks in repo

• Use tools like Husky

3. Version Control Your Hooks

Use frameworks or custom scripts to distribute hooks across teams.

4. Avoid Over-Engineering

Don’t turn hooks into full CI systems.

Keep them:

• Lightweight

• Focused

5. Combine Client + Server Hooks

Client hooks:

• Improve developer experience

Server hooks:

• Enforce compliance

Common Challenges & Solutions

Problem: Hooks Not Shared

Solution: Use tools like Husky or pre-commit framework

Problem: Developers Bypass Hooks

git commit --no-verify

Solution: Use server-side hooks for enforcement

Problem: Performance Issues

Solution:

• Optimize scripts

• Cache results

Git Hooks vs CI/CD

Conclusion

Git Hooks may seem like a small feature in the vast ecosystem of modern DevOps tooling, but their impact is anything but small. When implemented thoughtfully, they become a critical layer of automation that strengthens your development workflow from the very first line of code.

Throughout this guide, we explored how Git Hooks can:

• Enforce code quality and consistency

• Catch issues before they reach CI/CD pipelines

• Enable shift-left testing and security practices

• Automate repetitive development tasks

• Improve overall engineering efficiency

The true power of Git Hooks lies in their simplicity. With just a few lines of scripting, you can introduce guardrails that prevent costly mistakes, reduce technical debt, and create a more disciplined development culture.

However, like any tool, their effectiveness depends on how you use them.

The key is to strike the right balance:

• Keep hooks lightweight and fast

• Focus on high-impact validations

• Combine client-side flexibility with server-side enforcement

• Integrate them seamlessly with your CI/CD and DevSecOps workflows

For DevOps engineers — especially those working with infrastructure automation tools like Terraform or cloud platforms like Azure — Git Hooks can be extended even further. From validating infrastructure code to enforcing policy-as-code, they can serve as an early checkpoint in your entire delivery pipeline.

Start small, iterate fast, and scale gradually.

Implement a simple pre-commit hook today — perhaps for linting or secret detection and observe the immediate improvement in your workflow. From there, evolve your hooks into a robust automation layer that complements your CI/CD pipelines and strengthens your DevOps maturity.

In a world where speed, quality, and security must coexist, Git Hooks offer a practical and elegant solution to bring them together.

Share DevOps IN SPACE

Git is the backbone of modern software development, enabling developers and DevOps engineers to track changes, collaborate efficiently, and manage code history. However, even experienced developers occasionally run into situations where they need to undo a commit, recover lost work, or temporarily save unfinished changes.

This is where Git’s powerful recovery and history-management commands come into play.

Commands like Git Reset, Git Revert, Git Stash, and Git Reflog provide developers with the ability to safely manage mistakes, recover deleted commits, and maintain a clean commit history. Whether you’re fixing a faulty commit, switching branches during development, or recovering work after an accidental reset, these tools are essential for maintaining productivity and code stability.

Understanding the difference between these commands is critical because each one serves a different purpose in Git workflow management:

• Git Reset helps rewrite local commit history.

• Git Revert safely undoes commits in shared repositories.

• Git Stash temporarily saves work in progress.

• Git Reflog helps recover commits that appear lost.

In this guide, we’ll explore each command in detail, including practical examples, real-world development scenarios, and best practices for using them safely in collaborative environments.

By the end of this article, you’ll have a clear understanding of when to use reset, revert, stash, or reflog, helping you manage Git history with confidence and avoid common mistakes.

Why Git Recovery Skills Are Important

In real-world development environments, mistakes are inevitable. You might:

• Commit incorrect code

• Push broken changes to a repository

• Accidentally delete commits

• Need to switch branches while your work is incomplete

Git’s recovery commands allow developers to safely undo changes without losing valuable work.

Knowing how to use these commands effectively is especially important in modern development workflows that involve:

• CI/CD pipelines

• Multi-developer repositories

• Feature branching strategies

• Production deployments

Understanding Git History and Commit Safety

Before diving into the commands, it’s important to understand how Git tracks changes.

Git stores project history through commits, which represent snapshots of your project at specific points in time.

Three important components exist in Git:

1. Working Directory – The files you are currently editing

2. Staging Area (Index) – Files prepared for the next commit

3. Repository History – The stored commits

Each command we’ll discuss interacts with these components differently.

For example:

• Git Reset changes commit history.

• Git Revert creates a new commit that reverses changes.

• Git Stash temporarily saves uncommitted work.

• Git Reflog helps recover lost commits.

Git Reset: Undoing Commits Locally

What is Git Reset?

git reset is used to undo commits by moving the HEAD pointer to a previous commit.

It is typically used when you want to modify or remove commits that haven’t been shared with others yet.

Because it rewrites history, it should be used carefully—especially in shared repositories.

Types of Git Reset

Git reset operates in three different modes.

1. Soft Reset

A soft reset moves the HEAD pointer but keeps changes staged.

Command: git reset --soft HEAD~1

Effect:

• Removes the last commit

• Keeps all changes in the staging area

Use case:

• When you want to edit the previous commit.

Example scenario:

You committed code but forgot to add one file.

2. Mixed Reset (Default)

A mixed reset removes the commit and unstages the changes but keeps them in the working directory.

Command: git reset --mixed HEAD~1

Effect:

• Removes the last commit

• Changes remain in your working directory

Use case:

• When you want to re-stage files differently.

3. Hard Reset

A hard reset completely removes commits and deletes changes.

Command: git reset --hard HEAD~1

Effect:

• Removes the commit

• Deletes staged changes

• Deletes working directory changes

Use case:

• When you want to completely discard changes.

  

Warning: Hard reset can permanently delete work.

Git Revert: Safely Undoing Commits

What is Git Revert?

git revert creates a new commit that reverses changes made by a previous commit.

Unlike reset, it does not change commit history.

This makes it safe for shared repositories.

Git Revert Example

Suppose a commit introduced a bug.

You can revert it using: - git revert <commit-id>

Git will:

1. Create a new commit

2. Apply the opposite changes of the specified commit

Reverting Multiple Commits

You can revert multiple commits as well.

Example: git revert HEAD~3..HEAD

This command reverts the last three commits.

When Should You Use Git Revert?

Use revert when:

• The commit has already been pushed

• Other developers may have pulled the changes

• You want to maintain a transparent commit history

Example scenarios:

• Production bug rollback

• Undoing faulty merge commits

• Reversing incorrect configuration changes

Git Stash: Saving Work in Progress

What is Git Stash?

Sometimes you need to switch branches, but your work is incomplete.

git stash temporarily saves your changes so you can return to a clean working directory.

It’s like putting your current work on a temporary shelf.

Basic Git Stash Command

git stash

This command:

• Saves your working changes

• Restores the working directory to the last commit state

Viewing Stashed Changes

You can view saved stashes using: git stash list

Example output:

stash@{0}: WIP on feature-login
stash@{1}: WIP on payment-module

Applying a Stash

To restore a stash:

git stash apply

This applies the latest stash without removing it.

Applying and Removing a Stash

git stash pop

This command:

• Applies the stash

• Removes it from the stash list

Naming a Stash

For better organization, you can name your stash.

Example:

git stash push -m “Work in progress on login feature”

When Should You Use Git Stash?

Common scenarios include:

• Switching branches to fix urgent bugs

• Pulling updates before finishing current work

• Temporarily saving incomplete changes

Git Reflog: Recovering Lost Commits

What is Git Reflog?

git reflog is one of Git’s most powerful recovery tools.

It records every movement of the HEAD pointer, including:

• Commits

• Resets

• Checkouts

• Rebases

Even if a commit is removed from history, reflog can still help recover it.

Viewing Reflog

Command: git reflog

Example output:

a1b2c3 HEAD@{0}: reset: moving to HEAD~1
d4e5f6 HEAD@{1}: commit: added login feature
g7h8i9 HEAD@{2}: checkout: moving to main

Recovering a Lost Commit

Suppose you accidentally ran: - git reset --hard HEAD~1

Your commit appears lost.

You can recover it using reflog.

Step 1: Find the commit in reflog.

git reflog

Step 2: Restore the commit.

git reset --hard <commit-id>

Your work is restored.

Real-World Recovery Scenarios

Git reflog is extremely useful when:

• A branch was accidentally deleted

• Hard reset removed commits

• Rebase caused loss of changes

• Commit history was rewritten

It acts as a safety net for Git history mistakes.

Git Reset vs Revert vs Stash vs Reflog

Quick summary:

• Reset rewrites history.

• Revert safely undoes commits.

• Stash temporarily saves work.

• Reflog recovers lost history.

Best Practices for Managing Git History

To avoid major issues while working with Git, follow these best practices.

Avoid Hard Reset on Shared Branches

Running: git reset --hard

on a shared branch can disrupt teammates’ work.

Use Revert for Public Commits

If a commit has already been pushed, prefer: git revert

instead of reset.

Use Stash Before Switching Context

Before switching branches, stash unfinished work.

This prevents merge conflicts and lost changes.

Use Reflog as a Recovery Tool

If you ever think your work is lost, run: -git reflog

Chances are, Git still remembers the commit.

Conclusion

Git provides powerful tools not only for tracking changes but also for recovering from mistakes and managing code history effectively. Commands like Git Reset, Git Revert, Git Stash, and Git Reflog form an essential safety net for developers working in fast-paced development environments.

Each command plays a specific role in handling different scenarios:

• Git Reset is useful for rewriting local history before sharing commits.

• Git Revert provides a safe way to undo changes in shared repositories without altering commit history.

• Git Stash helps developers temporarily store unfinished work when switching tasks or branches.

• Git Reflog acts as a powerful recovery tool that can restore commits even after accidental resets or rebases.

Mastering these commands not only improves your Git workflow but also increases confidence when working with complex repositories, CI/CD pipelines, and collaborative development teams.

For developers and DevOps engineers, understanding these recovery mechanisms can mean the difference between losing hours of work and recovering it in seconds.

As you continue working with Git, practicing these commands in real scenarios will help you build stronger version control skills and maintain cleaner, safer commit histories.

If you want to become truly proficient with Git, learning how to recover, revert, and manage history effectively is just as important as committing code.

But very few truly understand the difference between:

git pull
git fetch

And that small misunderstanding?

It’s responsible for countless merge conflicts, broken branches, and unstable CI pipelines.

Let’s fix that: -

What git fetch Actually Does

When you run:

git fetch origin

Git:

• Downloads new commits from the remote repository

• Updates your remote-tracking branches (origin/main)

• Does NOT touch your current working branch

Your code stays exactly the same.

Think of it as:

“Let me see what changed before I touch anything.”

This makes git fetch ideal for:

• Reviewing teammate changes

• Safe DevOps workflows

• Production-sensitive branches

• Controlled merge strategies

What git pull Actually Does

When you run:

git pull origin main

Git performs:

1. git fetch

2. git merge (or rebase if configured)

This means:

• Your local branch changes immediately

• Merge commits may be created

• Conflicts can appear instantly

Think of it as:

“Bring everything in and merge it now.”

That’s fast — but not always safe.

Why This Matters in DevOps

In real-world CI/CD environments, surprises are expensive.

Many experienced teams prefer:

git fetch
git diff origin/main
git merge origin/main

Why?

Because visibility before integration = fewer broken builds.

This is especially important when:

• Working with multiple contributors

• Managing protected branches

• Deploying via automated pipelines

• Handling microservices architecture

Small discipline in Git usage creates massive stability downstream.

When to Use What

The Mindset Shift

The real difference isn’t technical.

It’s psychological.

git fetch = Intentional workflow
git pull = Convenience workflow

Mature engineering teams optimize for control, not convenience.

If you’re serious about improving your Git workflow as a Developer or DevOps Engineer, mastering this distinction is foundational.

I wrote a more detailed practical guide with examples here:

Read the full breakdown:
https://medium.com/towards-aws/git-pull-vs-git-fetch-a-practical-guide-for-developers-and-devops-engineers-cc6766d68e6d

If you enjoyed this, consider subscribing.