Reading History and Undoing Small Mistakes

Previously in Part 2, you built your first repository, clinic-notes, and pasted two photos into the album with git add and git commit.

Today we learn to read — history, differences, single commits — and then we learn the level-one rescue moves for the small mistakes everyone makes. Keep your clinic-notes folder open; everything here is type-along.

Reading history: log

You met git log already — the full album, newest first. For a quicker flip-through, add --oneline:

git log --oneline

8d2c4b7 (HEAD -> master) Add notes from day two
f3a91c2 Add notes from day one

One line per photo: serial number, caption. When a project has hundreds of commits, this is the view you'll live in. (HEAD just means "you are here.")

Reading differences: diff

Open day-1.txt and add a second line, so the file reads:

Asha visited today, prescribed rest.
Follow-up: Asha reports feeling much better.

Save it, then ask Git exactly what changed:

git diff

--- a/day-1.txt
+++ b/day-1.txt
@@ -1 +1,2 @@
 Asha visited today, prescribed rest.
+Follow-up: Asha reports feeling much better.

Read the last two lines with me. A line starting with a space is unchanged — shown for context. A line starting with + was added. If you deleted something, it would appear with a - in front. That's the whole vocabulary: plus means new, minus means gone. Every code review you'll ever do is just reading these + and - lines.

One subtlety worth knowing early: plain git diff compares your messy room against the posed photo — working directory versus staged. Once you git add a file, plain diff shows nothing for it. To see what's posed and about to be photographed, use:

git add day-1.txt
git diff --staged

Same output as before — the change is simply standing in the staging area now. And to re-read any single old photo, caption and changes together, there's git show:

git show f3a91c2

(Use a serial number from your git log --oneline.) Commit the follow-up note before we move on: git commit -m "Add Asha's follow-up note".

The level-one rescue moves

Everyone stages the wrong file, ruins an edit, or mistypes a caption. Here are the three rescues that cover ninety percent of beginner life:

Let's actually perform each one, so your fingers learn them before an emergency.

Rescue one: unstage

Create a file called lunch-order.txt with anything inside — clearly not a clinic note. Pretend you got sloppy and staged everything:

git add lunch-order.txt
git status

It's under "Changes to be committed" — posing for a photo it has no business being in. Wave it out of the frame:

git restore --staged lunch-order.txt

Run git status: it's back to untracked. The file itself wasn't touched — it just stepped out of the pose. Go ahead and delete lunch-order.txt; it has served its purpose.

Rescue two: discard changes — the honest warning

Now open day-2.txt and mangle it — delete the line, type gibberish, save. Disaster! Except it isn't, because the last photo of this file is safe in the album:

git restore day-2.txt

Open the file again — good as the last commit. But I need to be straight with you: this command genuinely deletes your edits. There is no undo for the undo. Anything you typed since the last commit is gone, not in any trash can. Before you run git restore on a file, ask yourself, out loud if needed: "Am I sure I want to throw away everything I did to this file?" If yes, it's a wonderful rescue. If maybe — stop and run git diff first to see what you'd be losing.

Rescue three: fix the last commit

Create day-3.txt ("Meera brought her son for a vaccination.") and commit it with a deliberately clumsy caption:

git add day-3.txt
git commit -m "notes"

Ugh — "notes." Future-you deserves better. Replace the caption on that photo:

git commit --amend -m "Add notes from day three"

Check git log --oneline — the sloppy message is gone, as if it never happened. The same move rescues a forgotten file: stage it with git add, then git commit --amend --no-edit quietly tucks it into the previous commit, keeping the same message.

Teaching Git to ignore things

Some files should never be in the album: scratch notes, passwords, files a build tool generates. History is forever, and forever is a long time to carry junk (or worse, secrets). Create a file called scratch.txt — your personal scribble pad — and notice how git status nags about it. Now create a file named exactly .gitignore (yes, starting with a dot) containing one line:

scratch.txt

Run git status again: scratch.txt has vanished from the list. Git now pretends it doesn't exist. The .gitignore file itself, though, is a real part of the project — commit it:

git add .gitignore
git commit -m "Ignore the scratch pad file"

Writing captions people thank you for

Since we're fixing messages today: a good commit message has a short subject line — fifty characters or fewer, written as a command ("Add…", "Fix…", "Remove…") — and, when it matters, a body that explains why. The code shows what changed; only you can record why.

Bad:  fixed stuff
Bad:  changes to day 2 file and also the ignore thing

Good: Add Asha's follow-up note

      She recovered faster than expected, so the record
      needs the follow-up before her next visit.

Six months from now, "fixed stuff" tells you nothing. The good one tells you the whole story. Write for the tired, confused future person most likely to read it: you.

You can now read history, read changes, and undo the small stuff. Time for Git's superpower — the one that terrified us in the SourceSafe days and is pure joy now. In Part 4: branches, parallel universes for your code — and your first look at a real project's history.