Viewing Changes & Safe Undo

Fearless Experimentation Through Error Recovery

In Lesson 1, you discovered how commits save your work as "save points." But what happens between commits? You modify files, make mistakes, realize your approach is wrong. How do you recover?

The question this lesson answers: When you've edited a file and realize the changes are bad, how do you get back to the working version? When you've staged the wrong files, how do you undo staging without losing the files?

What makes this possible: Three Git commands that let you explore mistakes safely and recover from them:

• git diff: See what you changed
• git restore: Throw away changes you don't want
• git reset HEAD <file>: Unstage files you staged by accident

These commands are your safety net for fearless AI experimentation. Imagine you ask Claude Code to refactor your entire codebase. With these undo commands, you can commit first, let AI make changes, see what it did with git diff, and instantly restore to the working version if it went wrong.

---

Phase 1: Visualizing Changes with git diff

Setup: Create a Committed File

Let's start with a working project from Lesson 1. If you don't have one:

# Create a new folder for this lesson
mkdir git-lesson-2
cd git-lesson-2

# Initialize Git
git init

# Create a simple file
cat > shopping-list.txt << 'EOF'
Shopping List
=============

Groceries:
- Milk
- Eggs
- Bread
EOF

# Stage and commit
git add shopping-list.txt
git commit -m "Initial shopping list"

What these commands do:

• mkdir git-lesson-2 and cd git-lesson-2 = create and enter new folder
• git init = initialize Git in this folder
• cat > shopping-list.txt << 'EOF' = create a file with multiple lines of text
  • cat > = create new file and put text into it
  • << 'EOF' = everything until "EOF" goes into the file (this lets you type multiple lines)
• git add and git commit = save this file as a commit (from Lesson 1)

Verify: Run git log to see your commit.

Activity 1: Modify a File and View Changes

Now you'll intentionally change the file and observe what changed using git diff.

Execute:

# Modify the shopping-list.txt file
cat >> shopping-list.txt << 'EOF'

Household:
- Dish soap
- Paper towels
EOF

# Check the status
git status

What this command does:

• cat >> = append text to end of existing file (the >> means "add to end", not "replace")
• << 'EOF' = same multi-line input technique (everything until "EOF")
• Result: adds household items to the shopping list without replacing groceries

Observe: You should see:

On branch master

Changes not staged for commit:
  (use "git add <file>..." to stage them)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   shopping-list.txt

Discovery Question: "Git knows the file changed. But what exactly changed? How can I see the differences?"

Activity 2: View Exact Changes with git diff

Execute:

# View changes
git diff shopping-list.txt

Observe: You'll see output like this:

diff --git a/shopping-list.txt b/shopping-list.txt
index abc1234..def5678 100644
--- a/shopping-list.txt
+++ b/shopping-list.txt
@@ -6,0 +6,5 @@ Groceries:
 - Bread
+
+Household:
+- Dish soap
+- Paper towels

Breaking Down the Diff Output:

• --- line: What the file looked like in the last commit
• +++ line: What the file looks like now
• Green + lines: New lines you added
• Red - lines: Lines you removed (we don't have any yet)
• White lines: Lines that didn't change (context)

What You Learned: git diff shows you exactly what changed since the last commit. No more guessing—you can see every addition and deletion.

Validation Checkpoint: Can you identify which lines are new additions? (The lines with + prefix)

---

Phase 2: Error Scenario - Deliberate Mistake

Now let's create an intentional mistake and discover how to recover from it.

Activity 3: Introduce a Syntax Error

Execute:

# Add bad formatting to shopping-list.txt (messy content on purpose)
cat >> shopping-list.txt << 'EOF'

This line has no formatting and breaks the structure
ALLCAPS AND CONFUSING TEXT
!!!random symbols@@@###
EOF

# View the broken file
cat shopping-list.txt

Observe: Your nicely formatted list is now messy:

Shopping List
=============

Groceries:
- Milk
- Eggs
- Bread

Household:
- Dish soap
- Paper towels

This line has no formatting and breaks the structure
ALLCAPS AND CONFUSING TEXT
!!!random symbols@@@###

Discovery Question: "Oh no! I broke the file. How do I get back to the version that worked?"

Note: This is the error scenario students face when AI generates buggy code—the file is broken, and you need to instantly recover.

Activity 4: View All Changes Including the Mistake

Execute:

# View all changes since last commit
git diff shopping-list.txt

Observe: The diff shows all your changes, including the messy text:

+This line has no formatting and breaks the structure
+ALLCAPS AND CONFUSING TEXT
+!!!random symbols@@@###

What You Learned: git diff lets you see the bad changes before committing. This is your inspection checkpoint before saving.

---

Phase 3: Understanding Recovery Paths

Two Ways to Undo: Manual Edit vs. git restore

You have two options:

Option A: Manually Edit the File

• Open the file in your editor
• Delete the bad lines
• Save
• Verify with git diff again

Option B: Use git restore

• Let Git throw away all changes
• Instantly return to the last committed version
• Much faster and safer

Activity 5: Discover git restore

Execute:

# Throw away all unstaged changes
git restore shopping-list.txt

# Verify the file is restored
cat shopping-list.txt

Observe: The file is back to the clean version! The messy text is gone.

Verify:

# View diff again
git diff shopping-list.txt

Observe: No output. This means the file matches the last commit exactly.

Confirm with status:

git status

Observe: The file is no longer listed as modified.

On branch master
nothing to commit, working tree clean

What You Learned: git restore is your instant undo for unstaged changes. It's non-destructive (the file still exists, you're just reverting to the last saved version).

Key Insight: Unlike closing a document without saving in a word processor, git restore recovers the working version from your last commit. This is incredibly powerful—you can edit fearlessly knowing you can always go back.

---

Phase 4: Undoing Staged Changes

Now let's explore the staging area recovery. This scenario happens when you accidentally stage the wrong file.

Activity 6: Create and Stage a File You'll Change Your Mind About

Execute:

# Create a new file
cat > notes.txt << 'EOF'
These are my rough notes.
I don't want this in the project yet.
EOF

# Stage it by accident
git add notes.txt

# Check status
git status

Observe: You see:

On branch master

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	new file:   notes.txt

Discovery Question: "Wait, I didn't mean to stage this file. How do I unstage it without losing it?"

Activity 7: Discover git reset HEAD <file>

Execute:

# Unstage the file
git reset HEAD notes.txt

# Check status
git status

Observe: The file is still there, but no longer staged:

On branch master

Untracked files:
  (use "git add <file>..." to track them)
	notes.txt

nothing added to commit but untracked files exist

Verify the file exists:

# View its contents
cat notes.txt

Observe: The file contents are exactly as you left them. Nothing was lost.

What You Learned: git reset HEAD <file> unstages files without deleting them. The file returns to "untracked" or "modified" status, but it's still there. This is non-destructive undo for the staging area.

---

Understanding: Three Undo Commands and When to Use Each

You now know three Git commands. They have different purposes:

Decision Tree: Which Command for Your Scenario?

Scenario 1: You modified a file and want to see what changed

Command: git diff <filename>
Effect: Shows the changes (+ and - lines)
Data Loss: None—just viewing
When to use: Before deciding if changes are good or bad

Scenario 2: You modified a file and want to throw away changes

Command: git restore <filename>
Effect: Undoes unstaged changes, returns file to last commit
Data Loss: None—file still exists, just reverted to committed version
When to use: After seeing bad changes in git diff, want instant undo

Scenario 3: You staged a file by accident

Command: git reset HEAD <filename>
Effect: Unstages file, returns to working directory state
Data Loss: None—file still exists and unchanged
When to use: Realized you staged the wrong file, want to keep working on it

Scenario 4: You created a commit you want to undo ⚠️ CAUTION

Command: git reset --hard HEAD~1
Effect: Deletes the last commit AND all its changes
Data Loss: YES—commit is gone forever
When to use: Only if the commit is recent and unpushed to GitHub
⚠️ WARNING: This is DESTRUCTIVE. Use only when absolutely sure.

Key Distinction: Non-Destructive vs. Destructive

• git diff: Non-destructive (viewing only)
• git restore: Non-destructive (reverts to committed version, doesn't delete)
• git reset HEAD <file>: Non-destructive (unstages without deleting)
• git reset --hard: DESTRUCTIVE (deletes commit and changes)

Why this matters for AI safety: When AI generates code, you want non-destructive undo commands so you can recover instantly. The destructive commands are for nuclear options only.

---

Activity 8: Practice the Decision Tree

Here's a practice scenario. Identify which command you'd use:

Scenario A: You edited notes.txt, added 50 lines of text, then realized it's all wrong. The file is not staged yet. What do you do?

Answer

Use git restore notes.txt to throw away the changes and return to the working version. The changes are in your working directory, not staged, so git restore is the right command.

Scenario B: You accidentally ran git add shopping_list.txt but this file shouldn't be in the project. It's not committed yet, just staged. How do you fix it?

Answer

Use git reset HEAD shopping_list.txt to unstage it. The file will remain in your working directory but won't be staged. You can then delete it if you want with rm shopping_list.txt.

Scenario C: You modified settings.txt with test values, staged it, and before committing you remember these are just temporary test values. What do you do?

Answer

First use git diff --staged settings.txt to review the changes (are you sure these are test-only?). Then use git restore --staged settings.txt to unstage it. The file remains modified in your working directory so you can review or revert it.

---

Terminal Log Examples

Here's what these commands look like in real execution:

Example 1: git diff Output

$ git diff shopping-list.txt
diff --git a/shopping-list.txt b/shopping-list.txt
index 1234567..abcdefg 100644
--- a/shopping-list.txt
+++ b/shopping-list.txt
@@ -7,0 +7,5 @@ Groceries:
 - Bread
+
+Household:
+- Dish soap
+- Paper towels

Reading the output:

• Line starting with + = added line
• Line starting with - = removed line
• No prefix = unchanged context

Example 2: git restore

$ git diff shopping-list.txt
diff --git a/shopping-list.txt b/shopping-list.txt
...showing the messy text additions...

$ git restore shopping-list.txt

$ git diff shopping-list.txt
$ # No output = file matches last commit exactly

$ git status
On branch master
nothing to commit, working tree clean

Example 3: git reset HEAD

$ git add notes.txt

$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	new file:   notes.txt

$ git reset HEAD notes.txt
Unstaged changes after reset:
? notes.txt

$ git status
On branch master
Untracked files:
  (use "git add <file>..." to track them)
	notes.txt

---

Summary: Your Safe Undo Commands

You now have three non-destructive undo commands that make AI-assisted development safe:

Situation	Command	Safety Level
Want to see what changed	git diff <file>	100% safe—viewing only
Changed a file, want to undo	git restore <file>	100% safe—file recovers from last commit
Accidentally staged a file	git reset HEAD <file>	100% safe—file unstaged, still exists

Why this enables fearless AI experimentation:

1. Ask AI to generate code
2. Use git diff to inspect what it generated
3. If it looks wrong, use git restore to instantly undo
4. If you accidentally staged it, use git reset HEAD to unstage
5. Try again with better instructions

You're always one command away from recovery. This is the Git safety mindset.

---

Try With AI

Setup: Open ChatGPT (chat.openai.com) and explore how AI understands these undo commands.

Prompt Set:

Prompt 1 (Conceptual):

I accidentally staged the wrong files in Git.
I used: git reset HEAD wrongfile.txt

Does this command delete the file?
Explain what happens to the file after this command.

Expected Outcome: ChatGPT should explain that git reset HEAD only unstages the file—the file still exists and is unchanged. Compare its answer to what you learned in Activity 7. Does ChatGPT understand that this is non-destructive? If it says the file is deleted, that's a mistake—correct it by telling ChatGPT "Actually, the file still exists, just unstaged."

---

Prompt 2 (Scenario-based):

I'm working with ChatGPT to edit my project files.
ChatGPT made changes that broke my project.
I already committed the broken changes to Git.

I want to undo this commit and go back to the working version.

What Git command should I use?
Is it safe to use?
What will happen to the broken changes?

Expected Outcome: ChatGPT should suggest git reset --hard HEAD~1 or similar, and explain that this is destructive (the broken code disappears). Compare this to what you learned in Phase 3—this is the nuclear option, destructive undo for committed changes. Good to know, but we usually prefer git restore for uncommitted changes.

---

Prompt 3 (Practical):

I edited three files for my project.
- notes.txt: I'm happy with these changes
- draft.txt: This has mistakes, I want to throw away changes
- temp.txt: I staged this by accident, I want to unstage it

For each file, tell me the Git command I should use.
Explain why each command is the right choice.

Expected Outcome: ChatGPT should distinguish:

• notes.txt: No command needed, keep the changes
• draft.txt: git restore draft.txt (unstaged changes undo)
• temp.txt: git reset HEAD temp.txt (unstage)

Verify that ChatGPT understands the distinction between unstaging (reset) and discarding changes (restore). Remember: git diff, git restore, and git reset HEAD are safe commands—they won't permanently delete anything (unlike git reset --hard).

---

Optional Stretch Challenge:

Try this flow with a real project:

1. Create a file with multiple functions
2. Modify one function (introduce a bug on purpose)
3. Use git diff to see the bad change
4. Use git restore to recover
5. Modify a different function and stage it
6. Use git reset HEAD to unstage just that file
7. Verify with git status that one is unstaged and one still exists

This hands-on practice builds the muscle memory for error recovery that makes AI collaboration safe.