Version control (git)

The fastest way in is to stop thinking of git as a programmer’s tool and start thinking of it as undo for an entire project. You already know undo for one document, and you know its limits: it covers one file, it only remembers this session, and it’s gone the moment you close the app. Git removes all three limits. It watches every file in a folder at once, it keeps the history permanently, and it lets you jump back to any earlier moment — not the last five keystrokes, but the exact state of everything as it stood on Tuesday afternoon.

The unit of that history is a commit: a save point you create deliberately, with a short note saying what changed. That “deliberately” is the part worth sitting with. Git isn’t autosave. You decide that the work has reached a state worth being able to return to, and you mark it. The note matters as much as the snapshot, because a month later the history reads as an account of why the project looks the way it does — not just a pile of timestamps.

The folder itself, once git is watching it, is called a repository — “repo” in every conversation you’ll ever have about it. This is where the word “project” gets its edges: a repo is a folder with a complete memory of itself. Files you deleted three weeks ago are still recoverable from it. That’s disconcerting the first time you learn it and reassuring every time afterwards.

Here is why any of this appears in a product for non-programmers. When you hand a folder to an agent, you are letting software change many files at once, faster than you can read the results. What makes that a reasonable thing to do is not confidence that the agent is right. It’s that the cost of being wrong is bounded. Commit before you ask for something ambitious, and every possible outcome — brilliant, mediocre, catastrophic — is a few seconds away from being undone. Without that, “let’s see what it does” is a gamble; with it, it’s an experiment. Agentic work is one of the strongest arguments for version control that has ever existed, and it arrived long after git did.

A branch extends the same logic. It’s a parallel line of work: you split off from the main version, change whatever you like, and either fold the result back in or abandon it entirely. The office analogy is making a copy of the shared document so you can wreck it freely — except merging your edits back is a supported operation rather than a nightmare of reconciling two files. For agent work, a branch is the natural container for “try the whole redesign and let me look at it,” because abandoning the attempt costs nothing.

Day to day, you don’t need to memorize commands. Ask in plain language — commit this with a sensible message, what changed since this morning, put that file back the way it was before — and Claude handles the mechanics. What stays yours is the judgment, and it’s real judgment: what deserves a save point, what the note should say so it means something later, when a piece of work should get its own branch, and whether a change you’re about to keep is actually the one you wanted. That last question is reviewing changes, and it’s a separate skill.

The history answers questions the files can’t

The half of git people never reach is that a repository isn’t only files — it’s every version of those files, with a note attached to each change. That history is usually the fastest route to “why is this like this?” and “what broke?”, and you don’t need git log, git blame or git diff to get at it. You ask in the chat and Claude looks:

• the contact form worked last week and doesn’t now — what changed in server/index.js since then?
• why does saveMessage read the whole file before writing? When did that get added?
• who last changed this line, and what were they trying to fix?
• I haven’t looked at this project in a month. What’s changed since I was last here?

That last one is worth more than it looks when you come back to something you’ve forgotten: instead of opening twenty files at random you get oriented in thirty seconds. (The word blame is git’s, not a judgement — the feature tells you who is responsible for a line, not who is at fault. It is frequently you, six months ago.)

The instinct worth rewiring: when something breaks suddenly, “what changed?” beats “what’s there?” The cause usually isn’t in the file as it stands today, it’s in the difference between today and yesterday — so read the diff, not the code. The one caveat is that history is only as good as the messages people wrote. Claude will reconstruct the story from the diff when a commit says nothing but “fixes”, but it’s a reconstruction, not a record. That’s the practical argument for writing decent commit messages: you’re leaving the explanation your future self will go looking for.

Two honest limits. Git tracks files on disk, so it protects the project folder and nothing else — not the spreadsheet in your shared drive, not your CRM, not anything an agent changed through a connector. And the net only holds what you actually committed; work done since your last commit isn’t in it. Claude Code’s own checkpoints and undo are a useful shorter-lived safety layer inside a session, but they are not a substitute for a commit history you can still read next quarter.