Introduction

If you want to undo a Git change without rewriting history, the key idea is to add a new change that reverses the old one rather than deleting or editing existing commits. That is the safe approach for shared branches because it preserves the published history that other people may already have.

The main command for committed history: git revert

When a bad commit is already in history and you do not want to rewrite that history, use git revert.

git revert <commit>

This creates a new commit whose content is the inverse of the target commit.

For example:

git log --oneline -3
git revert abc1234

After that, the original commit still exists in history, but a new commit records the undo action. That is why revert is the standard answer on shared branches.

Undoing the latest commit non-destructively

If the most recent commit is the one you want to undo, the command is the same.

git revert HEAD

Git opens an editor for the revert commit message unless you provide one non-interactively.

git revert --no-edit HEAD

That keeps the undo operation explicit and reviewable.

Reverting multiple commits

If several recent commits should be undone, you can revert them one by one or stage several reverts before committing.

git revert --no-commit HEAD~2..HEAD
git commit -m "Revert last two commits"

That applies the inverse changes into your working tree and index, then records one new undo commit when you are satisfied.

Uncommitted changes are different

If the change has not been committed yet, you do not need git revert because there is no history entry to preserve.

To discard unstaged changes in a file:

git restore path/to/file

To unstage a file but keep the working-tree edit:

git restore --staged path/to/file

Those commands do not rewrite published history because no commit is being changed at all.

Why not reset

git reset can move branch pointers backward, which changes history shape from the branch's point of view. That is fine for private local cleanup, but it is not the standard answer when the requirement is specifically "do not rewrite history."

So for committed public history:

• use git revert
• avoid git reset --hard or history-editing rebases

Reverting merge commits

Merge commits need extra care because Git must know which parent to treat as the mainline.

git revert -m 1 <merge-commit>

That is still non-destructive in the history sense, but the semantics are more subtle than reverting a normal single-parent commit. If you are undoing a merge on a shared branch, verify the parent choice first.

Common Pitfalls

The biggest mistake is using git reset --hard on a shared branch when the real goal was a safe public undo. That rewrites branch history and can disrupt collaborators.

Another issue is trying to use git revert for uncommitted file edits. revert works on commits, not on raw working-tree state.

It is also easy to forget that reverting a commit does not erase it from history. That is the point, but it surprises people who expect the original commit to disappear.

Finally, merge reverts are not as simple as ordinary reverts. If a merge is involved, check the parent numbering and test the result carefully.

Summary

• Use git revert to undo committed changes without rewriting history.
• 'git revert HEAD is the standard way to undo the latest commit safely.'
• Use git restore and git restore --staged for uncommitted file changes.
• Avoid reset when the requirement is specifically to preserve shared history.
• A non-destructive undo adds a new commit; it does not erase the old one.