The Atomic Commit: Why Your Git History Is Business Intelligence

29 December 2025. I removed fifteen blog posts from the webuildstores site. Updated internal links. Added redirects. One commit. Thirty-three files changed. The message: “Content audit: Remove 15 posts, update internal links, add redirects.”

Three weeks later, rankings shifted. Not dramatically — a few positions on a handful of pages. The kind of movement that could be anything. Algorithm. Seasonal. Competitor activity. Or something I did.

I went to the git history to find out. And the git history said: thirty-three files changed. Fifteen posts removed, internal links updated, redirects added — all in one go. Which specific change caused the shift? Couldn’t tell you. The receipt was illegible.

Save Points

For years I treated commits the way I treated saving a Word document. Work for a few hours, hit save, write “updates” or “various fixes” or “WIP.” The history becomes a timeline of when someone stopped working, not what they actually did.

It works right up until the moment you need the history to answer a question.

The Shift

The shift didn’t come from a best practices article or a code review. It came from Claude Code.

When Claude Code starts a session, it reads recent git history to understand what’s been happening. Not the code — the messages. The commit messages are how the system picks up where the last session left off. What was built yesterday. What changed last week. What the trajectory looks like.

Feed it a history of “updates” and “various fixes” and it sees nothing. It starts cold. Every session is a blank page regardless of what was built the day before.

Feed it a history where each commit describes one logical change — “Atlantic Rubber: mark inactive, £330 MRR lost” or “Energy Pages: add Heat Pumps pillar (5 new pages)” — and the system picks up the thread. It knows what was built. It knows where things stand. It knows the direction.

The commit message became the handover note between sessions.

The Discipline

An atomic commit captures one logical change. One decision. One thing that happened and why.

Not “updated the site.” What did you update? “Added the chimney repairs page to Roofing Crew.” That’s a commit. “Fixed the broken link on the Anglia Labels homepage.” That’s a commit. “Removed 2,511 out-of-stock product pages from Indoor Luxury.” That’s a commit — and six months from now, when someone asks why the page count dropped, the answer is right there.

The rule I use: if you’re writing “and” in the commit message, it should probably be two commits.

This costs time in the moment. Instead of one commit at the end of a session, you might make five or ten. Each one staged deliberately, each message written with intent. It feels slower. But the cost of not doing it compounds invisibly — every future question about “what happened” becomes archaeology instead of lookup.

Songlines

Aboriginal Australians developed songlines — navigational paths across the continent encoded in songs, stories, and ceremonies. Walk the songline and you walk the route. Sing the song and you navigate the landscape. The history isn’t stored in a library. It’s embedded in the practice of moving through the territory.

Welsh bards did something similar. The oral tradition wasn’t a limitation — it was a discipline. Every word in a poem carried navigational weight because the poem was the only record. Get the word wrong and the history drifts. The precision wasn’t accidental. It was necessary.

Sloppy commits are like sloppy oral history. The broad strokes survive — “we went from here to there” — but the detail that makes the journey useful is gone. You know something happened in December. You don’t know which of the thirty-three changes mattered.

28 October 2025

Here’s where it pays off.

When I wrote Teaching Claude Code Taste, I needed the opening. The origin story of the pattern library. Not the dramatic moment — the unremarkable one. The commit nobody noticed at the time.

I ran git log. And the history surfaced it.

28 October 2025. “fix: Add Sharp dependency and starter template files.”

A dependency fix. Routine. Forgettable. Except it was the first commit to the starter template — the seed that grew into fourteen trade site templates and a shared pattern library. The beginning of something that didn’t know it was beginning.

That commit surfaced because it was atomic. One change, one message, discoverable. If it had been bundled into “various updates — October cleanup” it would have been invisible. The origin story would have been lost in the noise, and the opening of the article would have been weaker for it.

The Forensics Test

The Compounding

Atomic commits aren’t just better record-keeping. They’re a different kind of business intelligence.

When every commit describes one thing, the git log becomes queryable — not in the database sense, but in the “ask a question and get an answer” sense. “When did we lose Atlantic Rubber?” Search the history. There it is. Date, context, MRR impact — all in the message.

And here’s the part I didn’t expect: Claude Code reads this history at the start of every session. The better the history, the more context the system has. The more context it has, the less time I spend explaining what happened yesterday. The less time I spend explaining, the more time I spend building.

Every atomic commit written today makes every session tomorrow slightly more intelligent. That’s not a productivity hack. That’s infrastructure.

The Six-Month Test

I have a simple test for whether the discipline is worth it. Go back six months in your git history and try to answer a specific question. “Why did the Escudero Auto homepage change in November?” “When did we add the solar pillar to Energy Pages?” “What was the last thing we built for Jana Helps before Christmas?”

If your history can answer those questions in under a minute, the discipline is working. If it can’t — if the answer requires reading diffs, cross-referencing dates, and guessing from file changes — then your history is save points, not intelligence.

Every commit is a bet. You’re betting that one day, someone — or something — will need to know what happened and why. The atomic commit makes that bet pay off. The bundled commit makes it a coin flip.

I know which bet I’d rather make.

Read more about the system:

• Your Website Should Come With a Receipt
• Teaching Claude Code Taste
• Stop Chatting With AI. Start Building With It.
• Ingeniculture: The Word for What’s Missing
• The Magic Word

Every commit in this article is real. The git history doesn’t lie — that’s the whole point.