Reading a diff & undoing safely

See exactly what changed, and get back to safety when a change goes wrong.

Two skills round out the basics: reading a diff (seeing what changed) and undoing (getting back to safety). Together they make you fearless.

What a diff is

A diff shows exactly what changed between two versions — line by line. When your AI assistant edits code, the diff is how you check its work before trusting it. Learning to read one is the single best defense against “the AI changed something and I don’t know what.”

Run git diff to see your unsaved changes:

$git diff
diff --git a/greeting.js b/greeting.js
index e69de29..8b1a2c3 100644
--- a/greeting.js
+++ b/greeting.js
@@ -1,3 +1,3 @@
function greet(name) {
-  return "Hi " + name;
+  return "Hello, " + name + "!";
}

Ignore the noisy header lines. The part that matters is the bottom:

• Lines starting with - (often red) were removed.
• Lines starting with + (often green) were added.
• Lines with no mark are unchanged, shown for context.

So this diff says: the old greeting "Hi " + name was replaced with "Hello, " + name + "!". That’s it. A diff is just removed lines and added lines, side by side.

Undoing, from gentle to nuclear

Things go wrong. Here’s your ladder of undo, from safest to most drastic.

1. Throw away unsaved changes to one file. You edited a file, it’s worse, you haven’t committed. Restore it to the last commit:

$git restore greeting.js

The file snaps back to how it was at your last save point. (Your other files are untouched.)

2. Go back to how a whole project looked at a past commit. This is why you commit often — every commit is a place you can return to.

Putting the module together

You can now: take snapshots (commit), work safely in parallel (branch), see what changed (diff), and get back to safety (restore). That’s the core of version control — and honestly more than a lot of working developers can clearly explain.