Why Deleted Git Commits Are Usually Not Really Gone (And How to Recover Them)

Git is one of the most powerful version control systems ever built — but it can also feel terrifying when a commit suddenly disappears.

You accidentally ran:

git reset --hard

Or maybe someone force-pushed to the repository and your commit vanished from Bitbucket.

Panic starts.

“Is my code gone forever?”

In most cases — no.

One of the biggest misconceptions about Git is that deleted commits disappear immediately. The reality is that Git is designed to preserve history for a while, which means there’s often a recovery path available.

Let’s understand how it works and how you can recover deleted commits safely.

Understanding What “Deleting a Commit” Actually Means

There are different ways commits get “removed” in Git:

• git revert
• git reset --hard
• git rebase
• force push (git push --force)
• branch deletion

Each behaves differently.

The good news is that Git internally keeps references to commits even after they are no longer visible in the branch history.

That’s why recovery is often possible.

Scenario 1: Commit Was Reverted

Many developers think git revert deletes a commit.

It doesn’t.

Instead, Git creates a new commit that undoes the changes from the previous commit.

Example:

git revert abc123

This creates another commit that reverses abc123.

Your original commit still exists in history.

Recovery Options

You can either:

Option A — Revert the Revert

git revert <revert-commit-hash>

Option B — Cherry-Pick the Original Commit

git cherry-pick <original-commit-hash>

This reapplies the original changes.

Scenario 2: Commit Removed Using git reset --hard

This is where most panic happens.

Example:

git reset --hard HEAD~1

This moves the branch pointer backward and removes the commit from visible history.

But Git usually still remembers it.

Enter: Git Reflog

Git maintains a hidden reference log called reflog.

Run:

git reflog

You’ll see something like:

abc123 HEAD@{0}: reset: moving to HEAD~1
def456 HEAD@{1}: commit: Added payment gateway

Even though the commit disappeared from the branch, Git still knows about it.

Recover the Commit

Create a Recovery Branch

git checkout -b recovery-branch def456

Or restore directly:

git reset --hard def456

Your commit is back.

Scenario 3: Commit Deleted After Force Push

Force push rewrites remote history.

Example:

git push --force

This can remove commits from Bitbucket/GitHub history.

But recovery may still be possible if:

• another developer has the commit locally
• CI/CD pipelines cloned the repository
• local reflog still contains it
• pull requests still reference the SHA

In distributed systems like Git, copies exist everywhere.

That’s why recovery often works even after remote deletion.

Important: Git Garbage Collection

Git doesn’t keep unreachable commits forever.

Eventually, Git runs garbage collection (git gc) and permanently cleans unused objects.

By default, unreachable commits may survive for days or weeks depending on configuration.

That’s why acting quickly matters.

Best Practices to Avoid Losing Commits

1. Avoid Force Push on Shared Branches

Instead of:

git push --force

Use:

git push --force-with-lease

This adds safety checks.

2. Create Backup Branches Before Rewriting History

Before rebasing or resetting:

git branch backup-main

Tiny step. Huge protection.

3. Learn Reflog Early

git reflog is one of the most underrated Git commands.

It has saved countless developers from disaster.

Final Thoughts

Git can feel unforgiving at times, but its internal architecture is surprisingly resilient.

A deleted commit usually isn’t truly deleted immediately.

If you understand:

• reflog
• cherry-pick
• reset
• revert
• force push behavior

you can recover from most Git mistakes confidently.

The next time a commit disappears, don’t panic first.

Run:

git reflog

There’s a good chance your code is still there waiting to be recovered.