Seeing What Changed and Who Changed It

Two questions come up constantly once a project has any history at all. What did this particular commit do? And who wrote this line, and what were they thinking?

Git answers both in about ten seconds, and the second answer is the one that makes every argument in Chapter 2 about commit messages suddenly concrete.

One commit in full

You met this command in the last topic. git show prints a commit's details and its complete diff:

git show c8d1e07

This is how you inspect a change somebody describes to you in a sentence — or one you made yourself and cannot remember. The message says what it was for; the diff underneath says exactly what it touched.

Comparing two points

Sometimes the question is bigger than one commit: what has changed over the last week, or between two versions of the project?

git diff a3f9c21 c8d1e07

Git shows the combined difference between those two states, however many commits sit between them. Notice this is the same git diff from Chapter 2 — the command compares two things, and until now those two things were "the last commit" and "your folder".

Who wrote this line

You are reading index.html and one line makes no sense. Perhaps it is a strange piece of formatting, or a fact you cannot verify.

git blame index.html

Every line of the file gets a short hash, a name and a date in front of it. The line you are staring at names the commit that last changed it.

The command has an unfortunate name. In practice nobody uses it to assign fault, and on your own project every line is yours anyway. It is a lookup tool: line to commit.

From line to reason

The lookup on its own is only half of it. Take the hash blame gave you and run show on it:

git blame index.html
git show 5b2a9f3

The first command finds the change. The second prints its message and diff, which is where the reason lives. On Sandpiper: blame attributes the meeting-time line to this morning's commit, and show explains that the club hall moved to Thursdays.

This is also the moment the whole "write real commit messages" argument pays off in a way you can feel. If that commit had said update, the two-step would end in a shrug.

What this replaces

Look back at the first page of this book. Four questions that a folder of copies could not answer: what changed, when, why, who.

git show answers what. The log and blame answer when. Both print the author, which answers who. And the message answers why, provided somebody bothered to write one.

That is the whole promise of Chapter 1, delivered by three commands you now know. Everything after this chapter is about doing more work more safely, not about answering those questions better.