In daily Git development, we often need to undo some mistakes, such as committing incorrect code or accidentally deleting a file. Git provides three common tools: git reset, git revert, and git restore. These tools have similar functionalities but vary significantly in applicable scenarios, making them easily confused by beginners. Below, we detail their differences to help you choose correctly in different situations.

一、git reset: “Hard Deletion” of Branch Pointer Adjustment¶

1. Basic Concept¶

git reset primarily adjusts the branch pointer and optionally discards modifications from partial commits. It “moves” the branch pointer to a past commit, effectively “deleting” the commits after it (if not retained).

Vivid Analogy: Imagine three books on a shelf: A → B → C (with C being the latest). reset directly moves the pointer to B, making C appear “deleted” (though it may still exist, the pointer no longer points to it).

2. Syntax and Modes¶

# Syntax: git reset [mode] <target version>
# Modes: --mixed (default), --soft, --hard

• --mixed (Default):
  Resets the branch pointer and the staging area to the target version, preserving working directory changes.
  Example: Revert to the previous commit (HEAD~1):

  git reset HEAD~1  # Equivalent to git reset --mixed HEAD~1

After execution: The branch points to A, the staging area matches A’s state, but working directory retains C’s modifications (unstaged).

• --soft:
  Only resets the branch pointer, completely preserving staging area and working directory changes.
  Example: Revert to two commits back while keeping intermediate changes:

  git reset --soft HEAD~2

After execution: The branch points to A, but staging area and working directory still contain B and C’s changes (ready for re-commit).

• --hard:
  Completely discards all changes after the target version (branch pointer, staging area, and working directory all revert). Most dangerous!
  Example: Revert to three commits back and permanently delete intermediate changes:

  git reset --hard HEAD~3

After execution: Branch pointer, staging area, and working directory all match the target version; subsequent commits are permanently lost.

3. Applicable Scenarios¶

• Quick local rollback before push: For example, if you just committed incorrect code but haven’t pushed it, reset can immediately revert to a previous version.
• Branch pointer adjustment: For team-shared branches, quickly correct error nodes.

⚠️ Warning: Using reset --hard on already pushed commits will corrupt others’ history. Never use it in this case!

二、git revert: “Sticky Note” for Retaining Historical Records¶

1. Basic Concept¶

git revert creates a new commit with content that “reverses” a previous commit’s changes, completely preserving the original commit history.

Vivid Analogy: If you wrote an incorrect formula (B) on paper, revert adds a “correction note” (D) below it. The original error (B) remains, but D ensures everyone knows where the mistake was.

2. Syntax and Usage¶

# Undo the last commit (creates a new commit)
git revert HEAD~1  

# Undo a specific commit (via commit hash)
git revert a1b2c3d  # Replace a1b2c3d with the target commit hash

3. Core Features¶

• Complete history: Original commits are never deleted; instead, a new “revert commit” is added, ensuring all team members’ repositories sync to the correct history.
• Safe rollback: Even if the commit has been pushed to remote, revert safely rolls back without damaging team history.

4. Applicable Scenarios¶

• Rolling back remote branches: For example, an online bug caused by an old commit in a remote branch. revert is mandatory here (since reset would pollute history).
• Multi-person collaboration: Ensures all team members sync to the correct history without conflicts.

三、git restore: “Precise File Recovery”¶

1. Basic Concept¶

git restore (introduced in Git 2.23+) focuses on restoring files to a specific state (staging area or working directory) without adjusting branch pointers. It exclusively handles file operations.

Vivid Analogy: If you accidentally spilled coffee on a file, restore recovers it from a “historical backup” (e.g., a previous commit version) without affecting other files or modifying branch structure.

2. Syntax and Usage¶

# 1. Undo staging (restore file to working directory)
git restore --staged <filename>  

# 2. Restore a file to a historical version (working directory)
git restore --source=HEAD~1 <filename>  # Restore <filename> from HEAD~1

3. Common Scenarios¶

• Undo staging errors: If you mistakenly git add a file and want to unstage it:

  git restore --staged sensitive.txt  # Unstage sensitive.txt

• Restore a single file to a historical version: For example, if you modified app.js incorrectly and need to revert to yesterday’s version:

  git restore --source=2023-10-01 app.js  # Revert app.js to 2023-10-01

4. Applicable Scenarios¶

• Single file correction: When only one file needs to be reverted, without touching the entire branch.
• Undo staging operations: Replace the deprecated git reset HEAD <file> with a clearer git restore --staged.

四、Core Differences and Choices¶

Decision Guide:
- Local un-pushed, branch messy: Use reset (choose --mixed to retain changes, --hard for full rollback).
- Remote pushed, need history retention: Use revert (adds a revert commit to sync with the team).
- Single file, precise recovery: Use restore (targeted file recovery without affecting branches).

Summary¶

The core of Git undo operations lies in “scenario matching”:
- reset is like “physical deletion” of history (risky).
- revert is like “documenting mistakes” (safe, preserves history).
- restore is like “file first aid” (precise, branch-independent).

By considering whether commits are pushed and whether they impact team collaboration, choose the appropriate tool to efficiently resolve rollback needs and avoid pitfalls!