A Snapshot With a Reason

Saving copies of a file gets you one thing: what it looked like at some moment you can no longer name. What you actually want is to save the state of the project files you chose, write down why you saved them, and keep every save.

Git’s answer to that wish is called a commit, and it is worth meeting the idea before meeting any commands.

A commit is two things kept together:

1. A snapshot of the project files you chose to include at one moment. It records the selected project state, not merely the one file that changed.

2. A message you wrote, saying why.

That is genuinely most of it. Almost everything else in Git is a way of making, reading, or moving between commits.

Reading a history

Here is what a short history looks like when you ask Git to show it. Do not worry about the exact format, and do not try to memorize anything. Just read it.

a3f9c21  Fix the total in the summary table
7b2e880  Add the March figures
1c4d503  Start the quarterly report

Three snapshots, oldest at the bottom. Each has a short code identifying it and the message its author wrote.

Compare that to report-FINAL-actually.txt. The history answers the question the file name could not: why. Someone fixed a total. Before that, someone added March. The project has a story, and the story is written down.

Those short codes (a3f9c21 and friends) are how Git names each commit. They look unfriendly and you will almost never type one from memory. For now, just know they exist and that each one points at exactly one snapshot.

Snapshots, not differences

There is a natural assumption to check here, because it trips people up later.

You might reasonably guess that a commit stores what changed since last time. It is a sensible guess, and it is the wrong mental model. A commit records a complete snapshot of the selected project state at that moment.

Git will happily show you the difference between any two commits, and that is one of the most useful things it does. But it works out that difference by comparing two complete snapshots. It is not stitching a file together from a chain of edits.

This matters for a practical reason: it is why going back to an old commit is safe and reliable. You are not undoing a stack of changes and hoping the result is right. You are asking for a photograph that Git already has.

Why the message is not optional

It is tempting to treat the message as paperwork. New Git users write update, fix, stuff, asdf. Everyone has done it.

Here is the argument against it, and it is entirely selfish. The person most likely to read your commit messages is you, about four months from now, with no memory of this week. The message is the only part of a commit written in a language you think in. The snapshot can show you what the code looked like. Only the message can tell you what you were trying to do.

You do not need to write essays. Fix the total in the summary table is a good message: it says what changed and where, in words a human uses.

We will come back to what makes a message useful once you have written a few. For now, notice that Git asks you for one every single time, and that this is deliberate.

Next, we will look at what having a history like this actually lets you do, because the answer is bigger than “go back to an old version.”