Difference between reset and revert in Git - Trade-offs & Expert Analysis

Overview - Difference between reset and revert

What is it?

In Git, 'reset' and 'revert' are two commands used to undo changes, but they work differently. 'Reset' moves the current branch pointer to a previous commit, effectively changing history. 'Revert' creates a new commit that undoes the changes of a previous commit without altering history. Both help fix mistakes but serve different purposes.

Why it matters

Without clear ways to undo changes, fixing mistakes in code history would be risky or confusing. 'Reset' lets you clean up or rewrite history before sharing, while 'revert' safely undoes changes in shared history. Without these, collaboration would be error-prone and chaotic.

Where it fits

Learners should know basic Git concepts like commits, branches, and the commit history. After understanding reset and revert, they can learn about advanced history rewriting tools like 'rebase' and collaborative workflows involving pull requests.

Mental Model

Core Idea

Reset moves the branch pointer to erase or change history, while revert adds a new commit to undo changes without rewriting history.

Think of it like...

Imagine a notebook where reset is like tearing out pages to remove mistakes, and revert is like writing a new page that explains and corrects the mistake without removing any pages.

Current branch history:
┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐
│ CommitA │ → │ CommitB │ → │ CommitC │ → │ CommitD │
└─────────┘   └─────────┘   └─────────┘   └─────────┘

Reset --hard to CommitB:
Branch pointer moves back to CommitB, commits C and D are removed from current branch view.

Revert CommitC:
Adds new commit E that undoes changes from CommitC:
CommitA → CommitB → CommitC → CommitD → CommitE(revert C)

Build-Up - 7 Steps

1

Foundation

Understanding Git Commit History

Concept: Learn what commits and branches are in Git and how history is recorded.

Git saves snapshots of your project called commits. Each commit points to its parent, forming a chain called history. Branches are pointers to specific commits, usually the latest one.

Result

You understand that commits form a timeline and branches point to places in that timeline.

Knowing that commits are snapshots linked in order helps grasp how commands like reset and revert affect history.

2

Foundation

Basic Undo: What Does 'Undo' Mean in Git?

Concept: Explore the idea that undoing changes can mean different things depending on context.

Undoing can mean removing commits, changing files back, or adding new commits that cancel previous ones. Git offers multiple ways to undo, each with different effects on history and collaboration.

Result

You realize undo is not one single action but several, each suited for different situations.

Understanding that undoing is context-dependent prepares you to choose the right Git command.

3

Intermediate

How 'git reset' Changes History

🤔Before reading on: do you think 'git reset' deletes commits permanently or just hides them? Commit to your answer.

Concept: 'git reset' moves the branch pointer to a previous commit, optionally changing the working files, effectively rewriting history.

Using 'git reset --hard ' moves the current branch pointer to the specified commit and resets files to that state. Commits after that point are no longer referenced by the branch and become unreachable unless referenced elsewhere.

Result

The branch history looks like it never had the commits after the reset point, and files reflect the reset commit.

Knowing reset rewrites history explains why it can be dangerous on shared branches but useful for cleaning local mistakes.

4

Intermediate

How 'git revert' Preserves History

🤔Before reading on: does 'git revert' remove the old commit or add a new one? Commit to your answer.

Concept: 'git revert' creates a new commit that reverses the changes introduced by a previous commit, preserving the commit history intact.

When you run 'git revert ', Git applies the opposite changes of that commit and makes a new commit with those changes. The original commit remains in history.

Result

History shows all commits, including the original and the new revert commit, making the undo explicit and safe for shared branches.

Understanding revert adds history rather than removing it clarifies why it's preferred for undoing public commits.

5

Intermediate

Reset Modes: Soft, Mixed, and Hard

🤔Before reading on: which reset mode changes files, and which only moves the branch pointer? Commit to your answer.

Concept: 'git reset' has three modes controlling how it affects the branch pointer, staging area, and working files.

'--soft' moves the branch pointer but leaves staged and working files unchanged. '--mixed' (default) moves the pointer and unstages files but keeps working files. '--hard' moves the pointer and resets both staging and working files to the commit state.

Result

You can choose how much to undo: just history, staging, or files too.

Knowing reset modes helps tailor undo actions precisely without unintended file loss.

6

Advanced

When to Use Reset vs Revert in Collaboration

🤔Before reading on: is it safe to use 'git reset --hard' on a shared branch? Commit to your answer.

Concept: Reset is best for local, private branches; revert is safer for shared branches to avoid rewriting public history.

Reset changes history and can confuse collaborators if pushed to shared branches. Revert adds new commits, keeping history intact and collaboration smooth. Teams often forbid reset on main branches.

Result

You understand the collaboration risks and choose commands accordingly.

Knowing the impact on shared history prevents costly mistakes and broken workflows.

7

Expert

Hidden Effects and Recovery After Reset

🤔Before reading on: do you think commits removed by reset are lost forever? Commit to your answer.

Concept: Commits removed by reset are not immediately deleted; Git keeps them temporarily in the reflog, allowing recovery.

Git records branch movements in the reflog. After a reset, unreachable commits remain in reflog for some time. You can recover them using 'git reflog' and 'git reset' to a reflog entry.

Result

You can undo a reset if done by mistake within the reflog retention period.

Understanding reflog as a safety net changes how you view reset's risks and recovery options.

Under the Hood

'git reset' moves the branch pointer (HEAD) to a specified commit and optionally updates the index (staging area) and working directory files depending on the mode. This effectively rewrites the commit history from that point forward. 'git revert' creates a new commit that applies the inverse patch of a specified commit, preserving the original commit and history intact. Internally, revert uses the patch system to reverse changes and commit them as new history.

Why designed this way?

Git was designed to allow flexible history rewriting locally (reset) while preserving a safe, immutable history for collaboration (revert). Reset enables cleaning up mistakes before sharing, while revert ensures public history remains consistent and auditable. Alternatives like deleting commits outright would risk data loss and confusion in distributed teams.

Branch pointer (HEAD) movement:

Before reset:
HEAD -> CommitD -> CommitC -> CommitB -> CommitA

After 'git reset --hard CommitB':
HEAD -> CommitB -> CommitA
(commits C and D are unreachable but still in reflog)

Revert process:
CommitC changes
  ↓ (invert changes)
New CommitE applies inverse of CommitC
History:
CommitA -> CommitB -> CommitC -> CommitD
                      ↓
                   CommitE (revert C)

Myth Busters - 4 Common Misconceptions

Quick: Does 'git reset' delete commits permanently right away? Commit yes or no.

Common Belief: Reset deletes commits permanently and they cannot be recovered.

Reality: Reset moves the branch pointer and makes commits unreachable, but they remain in Git's reflog for some time and can be recovered.

Why it matters: Believing reset deletes commits causes unnecessary panic and fear of using reset, limiting effective history management.

Quick: Does 'git revert' remove the original commit from history? Commit yes or no.

Common Belief: Revert removes the original commit from history.

Reality: Revert adds a new commit that undoes changes but keeps the original commit intact in history.

Why it matters: Misunderstanding revert leads to confusion about why the original mistake still appears in history and can cause misuse.

Quick: Is it safe to use 'git reset --hard' on a branch shared with others? Commit yes or no.

Common Belief: Resetting a shared branch is safe and common practice.

Reality: Resetting shared branches rewrites history and can cause conflicts and confusion for collaborators.

Why it matters: Using reset on shared branches can break team workflows and cause lost work or complicated merges.

Quick: Does 'git revert' always succeed without conflicts? Commit yes or no.

Common Belief: Revert always applies cleanly without conflicts.

Reality: Revert can cause conflicts if the changes being undone overlap with later commits.

Why it matters: Expecting automatic success can lead to surprise conflicts and requires manual resolution.

Expert Zone

1

Resetting with '--soft' allows undoing commits while keeping changes staged, useful for regrouping commits.

2

Revert can be used to undo merge commits with special flags, but this is more complex and error-prone.

3

Reflog retention depends on Git configuration and garbage collection, so recovery windows vary.

When NOT to use

Avoid 'git reset' on branches shared with others; use 'git revert' instead to maintain history integrity. For rewriting multiple commits or cleaning history before sharing, use 'git rebase' or interactive rebase. For undoing uncommitted changes, use 'git checkout' or 'git restore'.

Production Patterns

Teams use 'git reset' locally to fix mistakes before pushing. On main branches, 'git revert' is standard to undo changes safely. Some workflows combine revert with pull requests to document fixes. Reflog is used by experts to recover lost commits after accidental resets.

Connections

Version Control Systems

Reset and revert are specific undo mechanisms within Git, a distributed version control system.

Understanding these commands deepens knowledge of how version control manages history and collaboration.

Undo and Redo in Text Editors

Reset and revert are like undo and redo operations but applied to project history instead of single files.

Knowing how undo works in editors helps grasp the difference between rewriting history (reset) and adding corrective actions (revert).

Legal Document Amendments

Revert is like adding an amendment to a legal document that cancels a previous clause, while reset is like removing pages from the document.

This analogy shows why preserving history (revert) is important for audit trails and accountability.

Common Pitfalls

#1 Using 'git reset --hard' on a shared branch and pushing it.

Wrong approach:

git reset --hard HEAD~2
git push origin main

Correct approach:

git revert
git revert
git push origin main

Root cause:

Misunderstanding that reset rewrites history and disrupts collaborators' copies.

#2 Expecting 'git revert' to remove the original commit from history.

Wrong approach:

git revert
# Then expecting 'git log' to not show the original commit

Correct approach:

git revert
# Understand that original commit remains, revert adds a new commit

Root cause:

Confusing undoing changes with deleting history.

#3 Not recovering commits after accidental reset because of fear they are lost.

Wrong approach:

git reset --hard HEAD~1
# No further action, thinking commits are gone

Correct approach:

git reset --hard HEAD~1
git reflog
# Find lost commit and git reset to it

Root cause:

Lack of knowledge about reflog and commit recovery.

Key Takeaways

'git reset' moves the branch pointer and can rewrite history, affecting staging and files depending on mode.

'git revert' safely undoes changes by adding new commits, preserving history for collaboration.

Reset is best for local, private fixes; revert is preferred for undoing changes in shared branches.

Commits removed by reset are recoverable via reflog for a limited time, preventing permanent loss.

Choosing between reset and revert depends on whether you want to rewrite history or preserve it.