Introduction

Undoing a pushed commit in Git can mean two very different things: creating a new commit that reverses the bad change, or rewriting branch history so the bad commit disappears. The safe answer for shared branches is usually git revert. History-rewriting commands such as git reset plus force-push are more dangerous and should be reserved for cases where rewriting remote history is acceptable.

Use git revert for Shared Branches

git revert creates a new commit that undoes the effect of an earlier commit.

git revert HEAD

This is the normal safe solution after a commit has already been pushed to a branch other people may use.

Why it is safe:

• it preserves published history
• collaborators do not have to recover from rewritten branch tips
• the undo action is explicit in the commit log

If you need to revert a specific older commit:

git revert <commit-hash>

Revert Several Commits Carefully

If a series of commits should be undone, revert them deliberately instead of guessing.

git revert OLDER_COMMIT^..NEWER_COMMIT

That creates a sequence of revert commits. The resulting history is longer, but it remains collaborative and safe.

Use reset Only When History Rewrite Is Acceptable

If the branch is private or everyone agrees to rewrite history, you can move the branch back and force-push.

git reset --hard HEAD~1
git push --force-with-lease

This makes the bad commit disappear from the branch tip, but it rewrites published history.

--force-with-lease is safer than plain --force because it refuses the push if the remote changed unexpectedly.

Use this only when you understand the impact on everyone using that branch.

Soft Reset Keeps the Changes Locally

Sometimes you want to undo the pushed commit but keep its file changes locally so you can fix them and recommit.

git reset --soft HEAD~1

This moves HEAD back but leaves the changes staged. You would still need to force-push if the old commit had already been pushed.

That makes it a branch-rewrite workflow, not a safe shared-branch workflow.

Recover With reflog If Needed

If you reset too far or lose track of the previous branch tip, git reflog can help you recover the old position.

git reflog
git reset --hard <reflog-hash>

reflog is not the normal undo tool for a shared branch, but it is very useful for recovering from local mistakes during history rewriting.

Choosing the Right Tool

A useful rule is:

• shared branch: git revert
• private branch or explicitly coordinated rewrite: git reset plus git push --force-with-lease

The important decision is not the command syntax. It is whether published history should be preserved.

Common Pitfalls

The most common mistake is using git reset --hard and force-push on a shared branch when a revert was the correct collaborative answer.

Another issue is using plain --force without understanding that it can overwrite remote work unexpectedly.

Developers also sometimes revert locally and forget to push the revert commit, leaving the remote branch unchanged.

Finally, before rewriting history, make sure you are really on the branch you intend to rewrite. That sounds basic, but it prevents expensive mistakes.

Summary

• Use git revert when undoing a pushed commit on a shared branch.
• Use git reset plus force-push only when rewriting remote history is acceptable.
• Prefer --force-with-lease over plain --force.
• Use git reflog to recover from local history-rewrite mistakes.
• Decide first whether you want a safe undo or a rewritten branch, then choose the command accordingly.