Reading git history with Claude

Back in Lesson 3.7, you learned that a repo is a folder plus a complete history of every change ever made to it. That history isn’t a curiosity — it’s often the answer to “why is this code like this?” And it’s the answer to “what broke?” when something worked yesterday and doesn’t today.

The history is just another thing in your folder. You can ask about it in plain English, and Claude will look.

You don’t need to learn git log, git blame, or git diff first. (You will, eventually — that’s Level 8. But not yet.)

What “history” lets you ask

A repo’s history holds answers to questions you couldn’t otherwise reach:

• What changed in this file recently?
• Who last touched this line, and what were they trying to do?
• What did this function look like before it was rewritten?
• What changed between yesterday and today?
• What was in the last commit?

Each of those used to require a separate git command and some squinting. Now they’re all the same shape of question.

The move

You point Claude at the project and ask:

what changed in src/lib/progress.ts in the last week, and why?

Claude will:

1. Look at the file’s recent history.
2. Open the relevant commits.
3. Read the diffs and any messages developers wrote describing the change.
4. Summarize it for you: “three changes — added XP claim logic, fixed a bug where the level overlay fired twice, renamed a helper. Each one done by you on these days, with these reasons.”

The history goes from opaque to legible in one turn.

Useful question shapes

The detective question — “what broke?”:

this was working last week and now it's broken. What changed in src/auth.ts since then?

The archaeology question — “why is it like this?”:

why does the `formatPrice` function handle three different currency formats? When did each one get added?

The blame question — “who and why?”:

who last changed this line: `if (user.role === 'admin' || user.role === 'owner')` — and what were they trying to fix?

(The word “blame” is git terminology, not a moral judgment. The feature is called git blame because it tells you who’s responsible, not who’s at fault. Try not to take it personally when you find out it’s you from six months ago.)

The catch-up question — “what’s new?”:

I haven't looked at this project in a month. What's changed since I was last here?

That last one is gold when you come back to a project you’ve forgotten. Instead of opening twenty files at random, you ask Claude to summarize the last month of commits and orient you in 30 seconds.

What “the history” actually contains

When Claude reads git history, it’s pulling from a few different things — all of them just files in the hidden .git/ folder. You don’t need to know how it works, but it’s worth knowing what’s in there:

• Commits — snapshots of every file at every save point, with a message describing the change.
• Diffs — for any two commits, the exact lines that were added or removed.
• Branches — different parallel versions of the project that may or may not have merged back together.
• Authors and dates — every commit knows who made it and when.

When you ask “why is this line here?”, Claude finds the commit that introduced the line, reads the message the developer wrote, looks at the surrounding diff, and tells you the story. It’s basically time travel for code.

The thing that trips people up

Two traps.

First, “what changed?” is often more useful than “what’s there?” When a bug appears suddenly, the cause isn’t usually in the file as it stands today — it’s in the difference between today and yesterday. Trained instinct says “read the code.” Better instinct says “read the diff.”

Second, history is only as good as the messages developers wrote. A commit titled “fixes” (we’ve all done it) doesn’t help much. Claude will read the diff anyway and reconstruct what happened from the code change itself, but it’ll be a guess. Don’t expect a clear “why” if the commit author didn’t leave one.

A clean history is a love letter to the future. We’ll get into writing it well in Level 8.

Practice

In any repo you have, try:

what's the last thing that changed in this project?

You’ll get back: the date, the file(s), and a sentence about what changed. From there, follow up — “why?”, “who?”, “show me the diff.” You’re driving a time machine.

What’s next

So far we’ve been trusting Claude’s answers a lot — what does this file do, where is this called from, what changed. What if it’s wrong? Reading mode has no permission prompt to save you. The next lesson is the most important habit in this whole level: how to check.