What is Git Reset vs Revert?
Compare git reset and git revert: how each undoes changes, the three reset modes, and when to safely use revert instead on shared team branches.
Expected Interview Answer
`git reset` rewrites history by moving the current branch pointer to a different commit, discarding or unstaging what came after, while `git revert` preserves history and instead adds a brand-new commit that undoes the effect of an earlier one.
Reset comes in three modes: `--soft` moves HEAD but keeps changes staged, `--mixed` (the default) moves HEAD and unstages changes while leaving them in the working directory, and `--hard` moves HEAD and discards changes entirely, which is destructive to uncommitted work. Because reset rewrites which commit a branch points to, it's unsafe on shared branches, anyone who already pulled the old commits will get confusing divergent history when they pull again. Revert, in contrast, never removes a commit; it computes the inverse of a target commit's changes and applies them as a new commit on top, so the original commit stays visible in history alongside the undo. As a rule of thumb: use reset for local, not-yet-pushed cleanup, and use revert for undoing something that's already been shared with others.
- Reset gives precise local control over staged, working, and committed state
- Revert is safe on shared branches because it never rewrites history
- Revert leaves a clear audit trail showing what was undone and when
- Reset --soft is handy for squashing or reorganizing recent local commits
- Choosing the right one avoids breaking teammates' pulled history
AI Mentor Explanation
Reset is like tearing the last few pages out of the scorebook to pretend those overs never happened, which only works safely if nobody else has already copied that scorebook. Revert instead adds a new page explicitly noting 'over 34 disallowed, runs reversed,' keeping the original entry visible while officially cancelling its effect.
Step-by-Step Explanation
Step 1
Choose reset for local, unpublished cleanup
If the commits you want to undo have not been pushed or shared, `git reset` is safe and lets you rewrite local history freely.
Step 2
Pick the right reset mode
`--soft` keeps changes staged, `--mixed` (default) unstages but keeps them in the working directory, `--hard` discards them entirely.
Step 3
Run the reset
`git reset --hard HEAD~1` moves the branch pointer back one commit and discards its changes completely from the working tree.
Step 4
Choose revert for shared history
If the commit has already been pushed and others may have pulled it, use `git revert <commit>` instead to avoid rewriting shared history.
Step 5
Run and push the revert
`git revert <commit>` creates a new commit undoing the target's changes; commit the message and `git push` it like any normal commit.
What Interviewer Expects
- Clearly distinguishes rewriting history (reset) from adding new history (revert)
- Knows the three reset modes and what each does to staged vs working changes
- Understands why reset is dangerous on shared/pushed branches
- Knows revert is the safe choice for undoing shared commits
- Can pick the right tool for a given scenario in an example
Common Mistakes
- Using `git reset --hard` on a branch that others have already pulled
- Confusing `reset --mixed` and `reset --hard`, accidentally losing work
- Thinking revert deletes the original commit instead of adding a new one
- Not realizing reset can unstage without touching the working directory
- Reverting a merge commit without specifying the `-m` parent number
Best Answer (HR Friendly)
“Reset is like erasing recent history so it looks like something never happened, which only works safely if you haven't shared that history yet. Revert is the safer option: it keeps the full record intact but adds a new entry that cancels out the earlier change, which is why it's preferred once work has been shared with others.”
Code Example
# Local, unpushed cleanup — safe to rewrite
$ git reset --soft HEAD~1
$ git status
Changes to be committed:
modified: src/config.ts
# Already pushed and shared — use revert instead
$ git log --oneline -1
abc1234 Enable risky feature flag
$ git revert abc1234
[main d4e5f6a] Revert "Enable risky feature flag"
1 file changed, 1 insertion(+), 1 deletion(-)
$ git push origin mainFollow-up Questions
- What is the difference between `--soft`, `--mixed`, and `--hard` reset?
- Why is `git reset --hard` dangerous on a shared branch?
- How do you revert a merge commit specifically?
- Can you undo a `git revert` if it was applied by mistake?
- How does `git reset` interact with the staging area versus the working directory?
MCQ Practice
1. What is the key difference between `git reset` and `git revert`?
Reset moves the branch pointer, potentially discarding commits, while revert never deletes history — it adds a new commit that reverses the target commit's effect.
2. Which reset mode discards changes from the working directory entirely?
`--hard` moves HEAD and wipes out both staged and working directory changes, making it the most destructive reset mode.
3. Why is `git revert` generally preferred over `git reset` on a shared branch?
Because revert adds a new commit instead of altering existing history, it avoids the divergent-history problems that reset causes on branches others have already pulled.
Flash Cards
Does git reset rewrite history? — Yes — it moves the branch pointer, which can discard or unstage existing commits.
Does git revert rewrite history? — No — it adds a new commit that undoes an earlier commit's changes, leaving history intact.
What does `git reset --soft HEAD~1` do? — Moves HEAD back one commit but keeps its changes staged, ready to be recommitted.
When should you prefer revert over reset? — When the commit has already been pushed/shared — revert avoids breaking teammates' pulled history.