The commit message

Every commit carries a short note — the commit message. In Lesson 4.6 you were on the reading end of these, asking Claude what past changes were for. Now you’re on the writing end: leaving the note that future-you will read.

The message explains why the change happened. The diff already shows what changed.

That split is everything. The diff — the exact lines added and removed — is the “what.” Anyone can see it. What the diff can’t tell you is the reason: the bug it fixes, the decision behind it, the thing that would otherwise take an afternoon to reconstruct. That’s the message’s job.

Good message, bad message

Bad messages are true and useless:

fixes
update
stuff

All accurate. None of them help the person (probably you) staring at this commit in three months wondering what happened.

A good message earns its keep at a glance:

Fix login crash when the email has a trailing space

Now future-you knows what broke and why this commit exists, without opening a single file. That’s the “love letter to the future” from Lesson 4.6 — this is where you actually write it.

The Claude way — and the one catch

Here’s the good news: Claude writes genuinely excellent commit messages. It reads the diff and summarizes the intent better than most people bother to. You say “commit this,” and you get a clear, well-formed message for free.

Your job shrinks to one thing: make sure it’s true and scoped.

Claude describes what it sees in the diff. So if the commit accidentally swept in unrelated changes — the exact thing Lesson 8.2 warned about — the message will either describe those too, or quietly gloss over them. A message that says “fix login bug” sitting on a commit that also renamed twelve files isn’t lying on purpose. But it’s lying. Read it before you accept it.

What’s next

You can make clean, well-labeled commits. But where do they go? And how do you try a risky change without breaking the version everyone else depends on? That’s what branches are for. Next.