In Git, “Reset” is a core operation used to undo or modify commit history. Unlike simply “deleting” files, it works by adjusting branch pointers and the state of the working directory/staging area. Beginners often make mistakes due to misunderstanding the differences between reset types. This article will break down the three common reset operations in the simplest way possible.

1. Why Use Reset?¶

Imagine you just committed a faulty version (e.g., added an extra line of code) or wrote the wrong commit message. You need to “go back” to fix the issue without losing subsequent potentially useful changes. Reset is the tool for this—it undoes commits while letting you retain or discard changes as needed.

2. Differences and Use Cases of the Three Reset Types¶

1. Soft Reset (--soft): Retain Workspace and Staging Area, Only Modify Commit History¶

• Key Feature: Only moves the HEAD pointer to the target commit; the staging area and working directory remain completely unchanged.
• Use Case: Adjusting commit content (e.g., fixing commit messages, merging minor subsequent changes).

Example:
Suppose you just committed a flawed version (C) and want to fix the commit message or adjust content before re-committing:

# Move back to the previous commit (HEAD~1 = "one commit before")
git reset --soft HEAD~1

• After execution, git log will show the history as A→B (the original C is “skipped”), but git status will show the staging area and working directory still retain C’s modified content.
• You can directly edit the commit message with git commit --amend or adjust the code and re-commit.

2. Mixed Reset (Default, --mixed): Reset Staging Area, Retain Workspace¶

• Key Feature: Moves the HEAD pointer to the target commit, resets the staging area, but preserves working directory changes.
• Use Case: Undo a commit while keeping changes to re-organize code before re-committing.

Example:
Suppose you committed version (C) and want to undo it but keep the code changes to re-submit correctly:

# Move back to the previous commit (default is mixed reset, no parameter needed)
git reset HEAD~1

• After execution, git status will show: The staging area reverts to B’s state (previously committed files may no longer be staged), but working directory modifications remain.
• You can re-stage changes with git add <file> and then git commit to create a new correct commit (A→B→C’).

3. Hard Reset (--hard): Permanently Discard Staging Area and Workspace Changes¶

• Key Feature: Moves the HEAD pointer to the target commit, resets both staging area and working directory, all unbacked-up changes will be permanently lost!
• Use Case: Need to “completely roll back” to a historical version (e.g., if a branch is messy and you want a clean state).

Example:
Suppose you made extensive changes in the working directory and want to revert directly to the previous stable version:

# Move back to the previous commit, discarding all changes
git reset --hard HEAD~1

• After execution, git log will show the history as A→B, and git status will show “clean working directory” (all changes are discarded).
• ⚠️ Warning: This operation is irreversible! If changes are unbacked-up, they will be lost forever after execution.

3. Quick Reference Table¶

4. Common Pitfalls and Pitfall Avoidance¶

1. Accidental Data Loss: After --hard, to recover lost changes, first find the target commit hash via git reflog (e.g., a1b2c3d), then run git checkout a1b2c3d. This only works for local, unpublished history.
2. Confusing Reset with Revert:
   - reset: Modifies history (directly deletes subsequent commits), suitable for local unshared errors.
   - revert: Creates a new commit (adds an undo operation), suitable for published history (to avoid team conflicts).
3. Use Specific Hashes Cautiously: If using git reset --hard <hash>, ensure the hash is the historical version you need; otherwise, you may roll back to an unrelated version.

5. Summary¶

• Soft Reset: Lightweight history modification, ideal for “recommitting while keeping changes”.
• Mixed Reset: Default behavior, suitable for “undoing a commit + reorganizing code”.
• Hard Reset: Dangerous! Only use when sure changes are unnecessary, and always back up important content before operation.

Remember: Reset’s core is “adjusting branch pointers,” not “deleting files.” Always run git status to confirm the state before operations to avoid accidental code loss!