Module 3 Lesson 4: Undoing changes

One of the main reasons we use Git is the "safety net." If you break your code, you should be able to undo your mistakes easily.

However, "Undoing" in Git depends on where the change currently is: in your Working Directory, the Staging Area, or the Repository. In this lesson, we cover all three levels.

1. Undoing Unstaged Changes (Working Directory)

If you have edited a file and realized you've made a mess, but you haven't run git add yet, you can discard your changes and revert to the last committed version.

# In modern Git (2.23+)
git restore <file>

# In older Git
git checkout -- <file>

Warning: This operation is destructive. Your local edits will be gone permanently because Git hasn't saved a snapshot of them yet.

2. Undoing Staged Changes (Staging Area)

If you have run git add and want to "unstage" the file (move it back to just being an edit in your folder), use:

git restore --staged <file>

This does not change the file’s content; it just removes it from the "Loading Dock" for the next commit.

3. Undoing Commits (Repository)

This is the most powerful "undo." There are two main ways to roll back a commit.

Method A: `git revert` (The Safe Way)

This command creates a new commit that does the exact opposite of a previous commit.

Use case: When you’ve already shared your code with a team. It keeps the history intact but fixes the error.

git revert <commit-id>

Method B: `git reset` (The "Eraser" Way)

This command moves the current branch pointer backward in time, effectively "erasing" commits from the history.

git reset --hard <commit-id>: Erases all commits since <commit-id> AND deletes all local changes in your files. Very dangerous.
git reset --soft <commit-id>: Moves the pointer back, but keeps your changes staged in the index. Best for "squashing" or re-doing your last few commits.

graph TD
    A["Commit 1 (Good)"] --> B["Commit 2 (Bad)"]
    B --> C["Commit 3 (Worse)"]
    
    C -- "git revert B" --> D["Commit 4 (Reverses B)"]
    C -- "git reset --hard A" --> A
    
    style A fill:#dfd
    style B fill:#fdd
    style C fill:#fdd
    style D fill:#dfd

4. The "Last Resort" (git reflog)

If you accidentally run git reset --hard and think you've lost your work, don't panic. Git tracks every time you move a pointer (like switching branches or resetting).

git reflog

This shows you a list of every single state your project has been in, even those that were "deleted." You can use the ID from the reflog to restore your repository.

Lesson Exercise

Goal: Recover from a mistake.

In your git-practice repo, make a change to a file and commit it.
Now, use git reset --hard HEAD~1 (this goes back one commit). Notice your file has returned to its previous state.
Run git reflog. Find the ID of the commit you just "deleted."
Run git reset --hard <that-id>.
Check your file—is your "deleted" work back?

Observation: You'll realize that it is almost impossible to truly "lose" data in Git once you have committed it.

Summary

In this lesson, we established:

git restore discards local edits (careful!).
git restore --staged removes items from the next commit.
git revert fixes mistakes by adding a new "inverse" commit (safe for teams).
git reset rolls back the history (dangerous for shared branches).
git reflog is the ultimate backup for your backups.

Next Lesson: Sometimes you don't want to "Undo" or "Log"; you just want to see exactly what changed. We’ll master git diff.