# Git Reset vs Git Revert

URL: https://softwaredictionary.org/compare/git-reset-vs-git-revert
Last updated: 2026-09-30

In short: Git reset moves a branch back to an earlier commit and drops the later ones, while git revert adds a new commit that undoes one, safe on shared branches.

## What is the difference between git reset and git revert?

`git reset` moves the current branch pointer to another commit and, depending on the mode, can also change the staging area and your working files. `git revert` leaves existing history alone and creates a new commit whose changes are the exact opposite of the commit you want to undo.

The difference is whether history is rewritten. Reset removes commits from the branch, which is fine for local work nobody else has seen but breaks things for collaborators who already pulled those commits. Revert only adds to history, so it is the safe way to undo a change that is already on a shared branch like `main`.

Reset has three main modes: `--soft` keeps the undone changes staged, `--mixed` (the default) keeps them as unstaged edits and `--hard` throws them away. Revert can undo any commit, not just the latest, so a typical workflow uses reset to clean up local commits and revert to back out a bad change that was already pushed.

A common misconception is that `git reset --hard` deletes commits forever. Git keeps the old commits for a while, and `git reflog` can usually find and restore them; uncommitted changes discarded by `--hard`, however, are truly gone.

| Aspect | Git Reset | Git Revert |
| --- | --- | --- |
| What it does | Moves the branch pointer to an earlier commit | Adds a new commit that reverses an earlier one |
| History | Rewritten: later commits drop off the branch | Preserved: the original commit stays in the log |
| Safe on shared branches | No, collaborators end up with conflicting history | Yes, it is an ordinary new commit |
| Working files | Kept or discarded, depending on `--soft`, `--mixed` or `--hard` | Changed only by applying the reverse of the commit |
| Which commits | Everything after the target commit | Any single commit or range, even an old one |
| After pushing | Needs a force push to update the remote | A normal push works |
| Best for | Cleaning up local commits before sharing | Undoing a change that is already published |

## Choose Git Reset when

- The commits exist only on your machine.
- You want to squash or redo recent local commits.
- You want to unstage files or discard local changes.

## Choose Git Revert when

- The commit has already been pushed to a shared branch.
- You want a clear record showing what was undone.
- You want to undo an older commit while keeping later ones.

## Frequently asked questions

**Can you undo a git reset?**

Usually, yes. `git reflog` lists where the branch pointed before, so you can reset back to that commit; only uncommitted changes lost with `--hard` cannot be recovered this way.

**Should I use reset or revert on main?**

Use revert. Shared branches like `main` should not have their history rewritten, and a revert commit undoes the change while keeping everyone's copies consistent.

**Can you revert a revert?**

Yes. Reverting the revert commit reapplies the original changes, which is a common way to bring a feature back after fixing it.

---

Software Dictionary: https://softwaredictionary.org/ · https://softwaredictionary.org/llms.txt