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.

Practice

1. What is the main difference between git reset and git revert?

easy

A. git reset creates a new commit, git revert deletes commits permanently.

B. git reset changes commit history, git revert creates a new commit to undo changes.

C. git reset only works on remote branches, git revert only on local branches.

D. git reset merges branches, git revert rebases branches.

Solution

1. Step 1: Understand git reset behavior

   git reset moves the branch pointer and can remove commits from history locally.

2. Step 2: Understand git revert behavior

   git revert creates a new commit that undoes the changes of a previous commit without changing history.

3. Final Answer:

   git reset changes commit history, git revert creates a new commit to undo changes. -> Option B

4. Quick Check:

   Reset changes history, revert adds undo commit [OK]

Hint: Reset rewinds history, revert adds undo commit [OK]

Common Mistakes:

• Thinking revert deletes commits
• Confusing reset with revert effects on remote
• Believing reset creates new commits

2. Which of the following is the correct syntax to undo the last commit using git revert?

easy

A. git revert HEAD

B. git revert --hard HEAD

C. git revert HEAD~1

D. git revert --reset HEAD

Solution

1. Step 1: Identify the commit to revert

   The last commit is referenced by HEAD.

2. Step 2: Use correct revert syntax

   git revert HEAD creates a new commit that undoes the last commit.

3. Final Answer:

   git revert HEAD -> Option A

4. Quick Check:

   Revert last commit with git revert HEAD [OK]

Hint: Revert last commit with 'git revert HEAD' [OK]

Common Mistakes:

• Using HEAD~1 to revert last commit
• Adding invalid flags like --hard or --reset
• Confusing revert syntax with reset

3. Given this sequence of commands:

git commit -m "Add feature A"
git commit -m "Fix bug B"
git reset --hard HEAD~1
git status

What will git status show after these commands?

medium

A. Working directory clean, last commit is "Add feature A"

B. Working directory clean, last commit is "Fix bug B"

C. Uncommitted changes from "Fix bug B" present

D. Error: reset failed

Solution

1. Step 1: Understand the commits and reset

   Two commits made: "Add feature A" then "Fix bug B". git reset --hard HEAD~1 moves branch back one commit, removing "Fix bug B" commit and resets files.

2. Step 2: Check status after reset

   Since reset was hard, working directory matches "Add feature A" commit, so no changes to commit.

3. Final Answer:

   Working directory clean, last commit is "Add feature A" -> Option A

4. Quick Check:

   Hard reset removes last commit and cleans changes [OK]

Hint: Hard reset moves HEAD and cleans working directory [OK]

Common Mistakes:

• Thinking reset keeps last commit
• Assuming changes remain after hard reset
• Confusing reset with revert effects

4. You ran git reset --soft HEAD~1 but your changes disappeared from the staging area. What is the likely mistake?

medium

A. You forgot to commit after reset, so changes are lost.

B. You should have used git reset --hard to keep changes staged.

C. You should have used git revert instead to undo the commit.

D. You ran git reset --soft but expected it to keep changes staged; it only moves HEAD.

Solution

1. Step 1: Understand git reset --soft effect

   This moves HEAD back but keeps changes staged (in index).

2. Step 2: Identify why changes disappeared

   If changes disappeared from staging, likely a misunderstanding: --soft keeps changes staged, but if you see no changes staged, maybe you checked wrong or used wrong flag.

3. Final Answer:

   You ran git reset --soft but expected it to keep changes staged; it only moves HEAD. -> Option D

4. Quick Check:

   Soft reset moves HEAD, keeps staged changes [OK]

Hint: Soft reset moves HEAD, does not remove staged changes [OK]

Common Mistakes:

• Confusing soft reset with hard reset
• Expecting soft reset to undo commit and unstaged changes
• Using revert when reset is intended

5. You pushed a commit to a shared repository but later found it causes issues. Which command should you use to undo the commit safely without rewriting history?

hard

A. git reset --hard HEAD~1

B. git checkout HEAD~1

C. git revert HEAD

D. git reset --soft HEAD~1

Solution

1. Step 1: Understand the problem with shared commits

   Reset rewrites history and can cause problems if commits are already pushed and shared.

2. Step 2: Choose safe undo method

   git revert HEAD creates a new commit that undoes the changes without rewriting history, safe for shared repos.

3. Final Answer:

   git revert HEAD -> Option C

4. Quick Check:

   Revert safely undoes shared commits without history rewrite [OK]

Hint: Use revert to undo shared commits safely [OK]

Common Mistakes:

• Using reset on shared branches causing conflicts
• Thinking checkout undoes commits
• Using soft reset expecting safe undo