Introduction

When you revert a Git commit with git revert, Git creates a new commit that undoes the changes. If you later want those changes back, you cannot simply re-merge or cherry-pick the original commit — Git sees the revert as intentional and skips the already-applied changes. The fix is to "revert the revert" — create a new commit that undoes the revert commit, effectively re-applying the original changes. Use git revert <revert-commit-hash> to undo the revert, or git cherry-pick the original commit if the history is complex.

Understanding Git Revert

1# Original commit
2git log --oneline
3# abc1234 Add login feature
4# def5678 Initial commit
5
6# Revert the login feature
7git revert abc1234
8# Creates a NEW commit that undoes abc1234's changes
9
10git log --oneline
11# 999aaaa Revert "Add login feature"
12# abc1234 Add login feature
13# def5678 Initial commit

git revert does not delete or modify history. It creates a new commit with the inverse diff. The original commit (abc1234) still exists in history, but its changes are undone by the revert commit (999aaaa).

Fix 1: Revert the Revert

1# Find the revert commit hash
2git log --oneline
3# 999aaaa Revert "Add login feature"
4# abc1234 Add login feature
5# def5678 Initial commit
6
7# Revert the revert — re-applies the original changes
8git revert 999aaaa
9
10git log --oneline
11# bbb2222 Revert "Revert "Add login feature""
12# 999aaaa Revert "Add login feature"
13# abc1234 Add login feature
14# def5678 Initial commit
15
16# The login feature is back!

This is the cleanest approach for shared branches. It preserves full history and creates an explicit record of the revert-then-re-apply decision.

Fix 2: Cherry-Pick the Original Commit

1# If you're on a different branch or the revert is complex
2git cherry-pick abc1234
3
4# If the original was multiple commits
5git cherry-pick abc1234 abc5678 abc9012
6
7# Cherry-pick a range of commits
8git cherry-pick abc1234..abc9012

Cherry-picking copies the original commit's changes into a new commit. This works when you want to selectively re-apply changes, but on the same branch where the revert exists, Git may detect that the changes were already applied and reverted.

Fix 3: Reverted Merge Commit

1# You merged a feature branch, then reverted the merge
2git log --oneline
3# fff3333 Revert "Merge branch 'feature/login'"
4# eee2222 Merge branch 'feature/login'
5# ...
6
7# Revert the revert of the merge
8git revert fff3333
9
10# OR: If you want to re-merge the feature branch with new fixes
11# First revert the revert, then merge again
12git revert fff3333
13git merge feature/login  # Now new commits from feature/login are included

Reverting a merge commit is especially tricky. If you later try to re-merge the feature branch, Git thinks all its changes are already in the target branch (because the merge commit exists in history). You must revert the revert first.

Fix 4: Interactive Rebase (Unpushed Only)

1# If the revert has NOT been pushed, you can remove it entirely
2git log --oneline
3# 999aaaa Revert "Add login feature"
4# abc1234 Add login feature
5# def5678 Initial commit
6
7# Interactive rebase to drop the revert commit
8git rebase -i def5678
9# In the editor, change 'pick 999aaaa' to 'drop 999aaaa'
10# Save and close
11
12git log --oneline
13# abc1234 Add login feature
14# def5678 Initial commit
15
16# The revert never happened — clean history

Interactive rebase rewrites history, so only use this for commits that have not been pushed to a shared remote. After pushing, other developers have the revert in their history.

Fix 5: Re-Apply with Modifications

1# If you want the original changes back WITH modifications
2git revert 999aaaa --no-commit  # Undo the revert without committing
3
4# Now make your additional changes
5# Edit files...
6
7git add .
8git commit -m "Re-apply login feature with bug fixes"

--no-commit stages the revert of the revert without creating a commit, giving you a chance to modify the changes before committing. This is useful when the original code needed fixes.

Identifying the Revert Commit

1# Find revert commits in history
2git log --oneline --grep="Revert"
3
4# See what a revert commit changed (should be inverse of original)
5git show 999aaaa
6
7# Compare original and revert
8git diff abc1234 999aaaa
9# Should show the exact inverse of the original changes
10
11# Find which commit was reverted
12git log --oneline 999aaaa -1
13# 999aaaa Revert "Add login feature"
14# The message tells you it reverted the "Add login feature" commit

Common Pitfalls

• Trying to re-merge a reverted merge branch: After reverting a merge, Git considers all the merged changes as already applied. Re-merging the same branch is a no-op. You must first revert the revert commit, then merge new changes from the feature branch.
• Using git reset on pushed commits: git reset --hard removes commits from local history but breaks the shared repository if the commits were already pushed. Other developers will have divergent histories. Use git revert for pushed commits.
• Forgetting --no-commit when modifications are needed: git revert <hash> creates a commit immediately. If you need to modify the re-applied changes (fix the bug that caused the revert), use --no-commit to stage changes first.
• Cherry-picking a commit that was already reverted on the same branch: Cherry-picking the original commit onto a branch where its revert exists can cause conflicts or be silently ignored because Git sees the net effect as zero. Revert the revert instead.
• Not communicating the revert-revert to the team: Reverting a revert creates confusing history (Revert "Revert "Feature X""). Write a clear commit message explaining why the changes are being re-applied and what was fixed, so other developers understand the intent.

Summary

• To re-apply a reverted commit, "revert the revert" with git revert <revert-hash>
• For reverted merge commits, revert the revert before attempting to re-merge the feature branch
• Use --no-commit to stage the re-applied changes and make modifications before committing
• Only use git rebase -i to drop revert commits that have NOT been pushed to shared remotes
• Use git log --grep="Revert" to find revert commits in history
• Write clear commit messages explaining the revert-revert to avoid confusing team members