Git: Age of Restore

If Git is a time-traveling filing cabinet, this section is about how to read the logs and safely reverse time when things go wrong.

Imagine you are coding an urgency classification module for a hackathon disaster management platform. It is 3:00 AM, the deadline is approaching, and you accidentally delete a crucial block of logic. If you haven’t committed yet, how do you get it back? What if you did prepare it for a commit (staged it), but realize it contains a cynical, dark-humor comment that the judges definitely shouldn’t see?

Git gives us a magnifying glass to see exactly what we’ve broken before we save it, and an “Undo” button to safely wipe away mistakes.

Formal Explanation & Mechanics

Time travel at this local level revolves around comparing and copying data between the Three Trees we established in Part 2.

A. The Magnifying Glass: Diffing When you ask Git what changed, it isn’t just looking at file sizes. It runs a difference-finding algorithm (typically a variant of the Myers diff algorithm) to find the Longest Common Subsequence between two files, computing the exact lines added or removed.

• Comparing Working Directory to Staging Area: This shows what you have changed but haven’t staged yet.
• Comparing Staging Area to Repository (HEAD): This shows what is staged and about to be committed.

B. The Undo Button: Restoring To “undo” a change, Git simply overwrites a file in one tree with the version of that file safely stored in another tree.

• If your Working Directory is messed up, Git can pull the clean version from the Staging Area or the Repository and overwrite your physical file.
• If your Staging Area has something you don’t want to commit, Git can pull the clean version from the Repository and overwrite the Staging Area (without touching your Working Directory files).

Concrete Examples & Code

Let’s look at the actual command-line workflow for these scenarios. We will use an urgency_classifier.py script as our example.

Scenario A: Inspecting Changes (git diff)

We modify your working directory. Let's see exactly what changed.

# You add a new line to your Python script
echo 'def classify(event): return "CRITICAL"' >> urgency_classifier.py

# Check the status
git status
# Output shows urgency_classifier.py is "Modified" (not staged)

# See the exact lines changed in the Working Directory
git diff
# Output: 
# --- a/urgency_classifier.py
# +++ b/urgency_classifier.py
# @@ -1,2 +1,3 @@
#  # Initial script
# +def classify(event): return "CRITICAL"

(The + indicates lines added, - indicates lines removed).

Scenario B: Undoing a Working Directory Mistake (git restore) You realize that one-line function is terrible. You want the file back exactly as it was in your last commit.

# Overwrite the file in the Working Directory with the version from the Staging Area/HEAD
git restore urgency_classifier.py

# Check status
git status
# Output: nothing to commit, working tree clean. Your bad code is gone forever.

Warning: This is a destructive action. The uncommitted changes in your Working Directory are permanently lost.

Get Mohammed Faham’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Scenario C: Unstaging a File (git restore --staged) You add a print statement containing a dark joke about system failures, and you accidentally run git add. It is now staged. You want to unstage it so it doesn't go into the commit, but you don't want to lose the code from your editor.

# You staged the file
git add urgency_classifier.py

# Unstage it (copy from HEAD down to the Staging Area)
git restore --staged urgency_classifier.py

git status
# Output: Changes not staged for commit. 
# Your file is still modified in your editor, but it is safely off the stage.

Common Misconceptions & Pitfalls

The Ghost of git checkout: If you read StackOverflow threads from before 2019, you will constantly see people using git checkout <filename> to undo changes.

What is happening? Historically, checkout was a heavily overloaded command. It was used both for switching branches (which we will cover next) AND for restoring files. This was incredibly confusing for beginners. In Git version 2.23, they split checkout into two explicitly named, safer commands: git switch (for branches) and git restore (for files). Always use git restore for files.

Hands-Off Coding Exercises

Level 1: The Diff

1. In your existing repository, create a file called readme.txt and commit it.
2. Add a new line of text to it.
3. Run git diff to view the addition.
4. Run git add readme.txt.
5. Run git diff again. (Notice it returns nothing! Why? Because git diff compares the Working Directory to the Staging Area. If they match, there is no diff).
6. Run git diff --staged to see the changes you are about to commit.

Level 2: The Rescue

1. Make a blatant typo in readme.txt. Do not stage it.
2. Use git status to verify it is modified.
3. Use git restore readme.txt to wipe away the typo and return to the clean state.

Here’s How I did it (don’t peek without trying it out yourself first) here

Sources & Recommended Resources

• Source: Chacon, S., & Straub, B. (2014). Pro Git. (Chapter 2.4: Undoing Things). git-scm.com/book/en/v2/Git-Basics-Undoing-Things
• Resource: The official Git documentation for restore: Run git help restore in your terminal. Reading the official man pages is an expert-level habit to build early.

What’s Next?

We have completed Phase 1: Beginner Mechanics. We now have complete control over a single linear timeline of code.

Next up: We enter Phase 2 with Part 4: Branching & Merging. This is the core superpower of Git — learning how to split our universe into multiple parallel timelines to build features independently; and then fuse them back together.
Until next time!