If you’re used to collaboration tools like Google Drive or Microsoft OneDrive, you might already be familiar with using technology to track different document versions. But, if my experience is anything to go by, most people don’t realise how easy it is to go back and keep track of what changed over time, and _final_FINAL_2’s are still pretty common. The tech that backs version control can be really helpful when you’re working with AI agents like Claude, though, so it’s worth building a basic understanding of what it is and how it works.

Managing different versions of documents has been a solved problem in the software engineering world for decades. Once you have more than one or two people working on a software project it becomes nearly impossible to keep track of everyone’s changes manually — and because any change can literally break the software, it’s really important to be able to keep track of them and manage them carefully.

This tooling — revision control, or source control software — also has practical uses beyond software development. A bit of source code is really just a scary looking document, after all. And for users of AI tools like Claude Code, it provides both a safety net and a focusing mechanism, giving you confidence that Claude’s work can be rolled back if it goes too far, and the ability to help you — and Claude — understand why you’ve each made the changes you have.

Git to the point

Probably the most common piece of revision control software used by software engineers today is a tool called git. Like all revision control software, git allows you to track changes to collections of files — repositories, or ‘repos’ — on your machine. Once you’ve made a change, you commit it to the repo, which is you saying, “I’m happy with this change and I want to make it official”. If you later make edits to the file and then change your mind about them, you can restore the previous version. You can even roll back to previous versions entirely, if you decide you need to.

Git lets you track the changes you make to files on your own machine, but it also allows you to share those changes with others — so if, say, you and I are working on a set of documents, we can both have our own copy, make our own changes, and then share them with each other when we’re done. In git’s terminology, this is pushing changes to a shared location, and pulling changes back from there. This process helps with productivity — we don’t have to worry if we’re editing the same files — but it also allows us to easily undo any changes we’re unhappy with. We can just step back to an earlier version. Services like GitHub make it easy to manage this sort of collaboration, and provide free options for individual users so it’s easy to get started. If you work for an organisation that does software development, there’s a good chance they’ll have professional licences for GitHub or an equivalent service.

If you haven’t installed git yet, you can find instructions on its official site. On Windows you can just download the setup application. On Mac, you’ll need to use the Terminal and first install a service called Homebrew — all the instructions can be found on that page, or ones it links to. (If you’re new to the Terminal, my earlier post Terminal Fear covers the basics.)

Claude is a git expert — I rarely, if ever, write git commands in the terminal myself any more — so there’s no need to worry about having to learn more scary command line jargon. Just tell Claude what you want to do and it will figure things out for you.

Teach, learn, collaborate

When you start working on a new project with Claude — in a new repo — tell it you want to use git to track changes and ask it to set things up. It will prompt you to run a few commands — you’ll see things like git init or potentially git add. These commands are setting up git’s version control in the folder you’re working in.

From there you should periodically, and especially after doing some significant work, ask Claude to commit any changes. This means “make a new version” — a snapshot of the document(s) you have in your repo. If future changes go wrong, you’ll be able to undo things all the way back to this point — or any point where you’ve made a commit. You’ll develop a feel for the right time to commit — too often, and you’re not snapshotting meaningful changes; too rarely, and rolling back to an earlier version means losing a lot of work.

Once you develop a rhythm for doing this, you unlock three new skills.

Teach Claude what matters

You can teach Claude what’s important to you. Let’s say you’ve been working together on developing a document. Claude has finished its latest iteration, but when you read it you find a bunch of things you don’t like. Factual errors, formatting issues, arguments that aren’t supported by the facts, or prose that just doesn’t sound like you. Sometimes, instead of talking to Claude directly about what you want to change, you’re better off just making the edits yourself. Before doing this, however, you should ask Claude to commit its changes. Why do that, when you don’t like its output?

Simple. Because, once you’ve made your updates, you can ask Claude to review what you’ve changed — and it will use a git diff command to see exactly what those changes are. Better than asking it to review, ask it to review and to ask you why you made those changes. What did you dislike about its approach? What was wrong? What can it learn? As you step through, you’ll likely spot Claude updating its memory files so that it can do a better job next time.

Understand Claude’s choices

The second skill is the same as the first, but in reverse. Let’s say you’ve committed a bunch of work, and then ask Claude to make an update — and it changes a ton of stuff. Instead of asking it to review your edits, this time you can ask it to explain itself. It will use the same git diff command, stepping through the changes one by one and allowing you to understand where it was coming from. You can course correct if need be, or just absorb what it did.

Share and collaborate

The final skill isn’t really about Claude. If you have a GitHub account, you can connect your local repo to one that lives on GitHub — and from there, you can share and collaborate with anyone else you choose to grant access to. In a business environment, this might mean your team, your peers, or even your boss. GitHub does a great job of making Markdown files look like presentable documents, so it’s a great way to share your work with whoever needs to consume it. And, if those people want to, they can clone your repo, make changes of their own, and suggest them back to you in a pull request, or ‘PR’. But that is a story for a whole other post.

Git and Claude are powerful allies. Like the terminal, git can seem like an archaic tool that’s only suitable for nerds, but it is genuinely powerful and useful for anyone who edits and collaborates on documents of any kind. Download it, give it a go with Claude, and let me know how you get on in the comments.