Git, Explained: The Safety Net You Need When AI Is Doing the Typing

I'll be honest: I was well into using AI coding tools before I properly understood what Git was doing. I'd see the word "commit" in a status bar and move past it. I'd hear "worktree" and nod like I knew. Then something would go sideways, and I'd realize I had no idea how to get back. So this is the guide I wish someone had handed me early.

You don't need to be a developer to understand this.

Track Changes, for everything

Most people have used Track Changes in Word or Google Docs at some point. You can see every edit, who made it, and revert any of them. Git does that, but for your entire project folder, every file, all at once.

The key difference: in Word, Track Changes runs automatically. In Git, you decide when to take a snapshot. Each snapshot you take is called a commit. Everything between one commit and the next is tracked, and you can step back to any previous commit, any time.

That's the whole idea. The vocabulary makes it feel complicated, but the mental model is simple: you're taking timed photos of your project so you always have an older version to go back to.

Committing: your save button

In a video game, you save before a hard section. If you lose, you reload and try again from that point. A commit works the same way.

You decide when to commit. You don't have to commit after every small thing. But the rule most people settle into: commit whenever something works. A page loads correctly, a form submits, a piece of copy is finalized. Take a snapshot. Write a short note about what you did.

Then if the next thing you try breaks everything, you have a clear path back. Roll back to the last commit, and you're on solid ground again.

That note you write (the "commit message") doesn't need to be a masterpiece. "Updated homepage headline" is enough. You're just leaving yourself breadcrumbs.

Branches: your experiment sandbox

A branch is a copy of your project that you can work in without touching the original.

Say your website is working well. You want to try a completely different layout for the homepage. You make a branch, try the new layout there, and if you love it, you bring those changes back into the main project. If you hate it, you close the branch and your original is exactly as you left it.

Think of it like making a duplicate of a spreadsheet before you try a complicated formula change. The duplicate is disposable. The original is safe.

Branches make experimentation free. You can try the ambitious version, knowing the working version is untouched.

Worktrees: two versions, open at the same time

This is the word that trips most people up the first time they hear it.

A worktree lets you have two different branches of your project open simultaneously, in separate folders, without duplicating everything by hand.

Here's why that's useful: sometimes you're experimenting in one branch, and a quick fix is needed on the main version right now. With a worktree, you open a second window for the main branch, make the fix, and go back to your experiment. No copying, no interruption, no losing your place.

Think of it as two browser windows, each showing a different tab, each running independently. Changes in one don't touch the other.

You may never need to set up a worktree yourself. A lot of AI tools handle this in the background. But the next time you see the word, you'll know: it's just two branches, open side by side.

Why this matters more when AI is in the mix

Here's where it clicks for me.

AI tools move fast. In a single session, an AI assistant might touch a dozen files, rewrite a function, update a config, and adjust a style. By the time something looks wrong, a lot has changed, across a lot of places.

"Undo" in your text editor won't reach all of it. A search through your history won't untangle it cleanly.

Git reaches all of it. One rollback, back to a commit you made before the session started, and everything is restored.

The upside is the same coin flipped over. Because you have a safety net, you can tell AI to try the bold version. Redesign the whole page. Try the different approach. If it works, commit it. If it doesn't, roll back and you've lost nothing.

The safety net changes how willing you are to experiment. And experimenting is how you find what actually works.

A few things to start doing

You don't need to master Git before you use it. Here's a small set of habits that'll give you most of the protection:

Commit when something works. Before you start a new session with an AI tool, take a snapshot. Before you try anything major, take another one. You want clear restore points.

Read the commit message back. "Updated stuff" is less useful than "fixed the contact form submit button." You're writing it for future-you, who may be confused and stressed.

Ask the AI about any error you get. Git error messages can look alarming. Your AI tool knows Git well. Paste the error and ask what it means. Nine times out of ten it's a three-word fix.

Let the tool handle the hard parts. Claude Code, Cursor, and most serious AI coding tools have Git built in. They'll prompt you to commit, show you what changed, and often handle branches and worktrees on your behalf. Your job is to understand what they're doing and why, so you're not flying blind.

The honest version

I still ask basic Git questions regularly. That's fine. The goal isn't to become a Git expert. The goal is to stop feeling like you're working without a net.

Once you know what a commit is, you make one. Once you know what a branch does, you're not scared to try things. The vocabulary stops being noise, and the system starts being a tool you trust.

If you're using an AI tool to build or run any part of your business, the Business Brain is worth a look. It's the step before this one: getting your business context, your voice, and your way of working loaded into AI so it actually knows your business before it starts changing things. The safety net matters more when the work it's protecting is yours.