Skip to main content
Git Basics
CHAPTER 08

Undoing Changes in Git

Updated: May 15, 2026
20 min read

# CHAPTER 8

Undoing Changes in Git

1. Introduction

The greatest fear a new developer faces is making a catastrophic mistake—deleting a critical file or breaking a production server. The entire reason we use Git is to eliminate this fear. Because Git takes immutable snapshots of our code, any mistake can be undone. However, the method you choose to undo a mistake depends entirely on *where* that mistake currently lives (Working Directory, Staging Area, or Commit History). In this chapter, we will learn the nuanced commands required to safely revert files, unstage mistakes, and travel back in time to rescue accidentally deleted work.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Discard uncommitted changes in the Working Directory (git restore).
  • Unstage files that were accidentally added (git restore --staged).
  • Safely undo published commits using git revert.
  • Understand the dangers of rewriting history with git reset.
  • Recover accidentally deleted files.

3. Beginner Explanation

Imagine you are typing a long essay.
  • git restore (The Backspace Key): You type a terrible sentence. You haven't saved the document yet. You just hit backspace to erase the terrible sentence.
  • git revert (The Apology): You wrote a terrible paragraph, saved the document, and emailed it to your teacher. You cannot un-email it. So, you write a *new* email that says: "Please ignore the third paragraph of my last email, it was a mistake." You are adding a *new* correction to the history.
  • git reset (The Time Machine): You wrote a terrible paragraph, saved it, but haven't emailed it yet. You literally rewind time to 5 minutes ago before the paragraph was ever written, erasing it from reality.

4. Undoing Uncommitted Changes

You edit index.html. You break the entire layout. You haven't typed git add or git commit yet. You just want to throw away your changes and return the file to exactly how it looked this morning.
bash
1 
git restore index.html

*Warning: This is permanent. Your uncommitted changes will be instantly destroyed and replaced by the last saved snapshot.*

5. Unstaging Files

You type git add . to move everything to the Staging Area. Suddenly, you realize you accidentally included an API password file! You need to pull it out of the suitcase before you zip it shut (commit).
bash
1 
git restore --staged password.txt

The file is safely moved back to your Working Directory, out of the Staging Area.

6. Mini Project: Restore Accidentally Deleted Work

Let's simulate a disaster and fix it.

Step-by-Step Walkthrough:

  1. 1. Ensure your working tree is clean (git status).
  1. 2. Delete a file: rm index.html
  1. 3. Panic. The file is gone.
  1. 4. Type git status. Git says: deleted: index.html.
  1. 5. Tell Git to reach into its vault and put the file back:

bash
1234567 
   git restore index.html
   ```
6. The file magically reappears on your hard drive, exactly as it was. Disaster averted.

### 7. Undoing Committed History (`revert` vs `reset`)
What if you successfully committed a bug, and pushed it to GitHub?
**The Safe Way (`git revert`):**

bash # Find the bad commit hash using git log (e.g., a1b2c3d) git revert a1b2c3d

123 
Git does not delete `a1b2c3d`. Instead, Git automatically writes a *brand new commit* that does the exact mathematical opposite of the bad commit (e.g., if the bad commit added a line, the new commit deletes that line). This preserves history and is 100% safe to push to a team.

**The Dangerous Way (`git reset`):**

bash git reset --hard a1b2c3d `` This physically rewinds the project back to that hash, completely erasing all commits that happened after it. *Never* do this if you have already pushed to GitHub, as it will break the repository for everyone else on your team.

8. Best Practices

  • Always use git revert on public branches: If a bug makes it to the main branch, never use reset. The main branch history must be immutable. Always use revert so there is a public record of the bug being introduced and subsequently fixed.

9. Common Mistakes

  • Confusing reset --soft and reset --hard:
  • --hard destroys your commits AND destroys the code changes in your text editor.
  • --soft destroys your commits, but leaves the code changes sitting in your text editor so you can fix them and try again.

10. Exercises

  1. 1. If you edit a file, but haven't staged it yet, what command do you use to discard those changes entirely?
  1. 2. Explain why git revert is safer than git reset when working collaboratively with a team on GitHub.

11. FAQs

Q: I used git reset --hard and accidentally deleted a week of work. Is it gone forever? A: Actually, no! Git has a secret, hidden log called the git reflog. It records every single movement of your pointers, even deleted commits. You can use git reflog to find the "deleted" hash, and then git reset --hard <hash> to magically travel back to the deleted timeline.

12. Summary

In Chapter 8, we conquered the fear of making mistakes by mastering Git's recovery mechanisms. We learned how to manipulate our immediate environment, discarding unsaved changes with git restore and pulling files out of the staging area with git restore --staged. We then addressed historical mistakes, contrasting the destructive, time-rewinding power of git reset with the safe, forward-moving apology of git revert`. By understanding these tools, we ensure that no data is ever truly lost, and that we can boldly experiment with our codebase.

13. Next Chapter Recommendation

We know how to use Git perfectly by ourselves. Now it's time to work with others. Proceed to Chapter 9: Collaborative Git Workflows.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Git Logs and History Management
Next Chapter Collaborative Git Workflows

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

❓ Related Quizzes 5