It's Time to Be a Git

Somewhere right now, someone with a working product is backing it up by zipping the folder and renaming it millionaire-maker-v2. Tomorrow there'll be a millionaire-maker-v3. This is version control by File Explorer, and in the age of AI-written code it's more common than it has ever been.

More people are building software than ever. Tools like Claude Code, Cursor, and Codex lowered the floor, and that's a genuinely good thing. But I keep seeing wild things done to source control by people who otherwise ship real work.

The other one I see constantly: everything committed straight to main. No branches, no stages. Every change goes live on the same single line of history, forever. A commit is meant to be a save point you can return to; used this way it's just an autosave with extra steps.

And here's the part that should bother you... this isn't only the no-code founders standing up a business on the back of AI tooling. It's junior engineers too, people who write real code every day and still treat Git like a mystery box they'd rather not open.

So who cares? If the AI writes the code and the zip-folder crowd ship products anyway, does any of this matter?

It matters the moment the project has to grow. Zipping the folder works for exactly one person on exactly one machine. The instant you need a second contributor, or two features in flight at once, or a way back to the version that worked last Tuesday, the whole scheme collapses. You can't scale an application if you don't even know where to start, and Git is where you start. It isn't bureaucracy. It's the thing that lets a project outgrow you.

Here's what I think actually keeps people out. It isn't the commands. Nobody is scared of saving a file. They're scared of the moment something breaks and they can't reverse it. The fear of Git is really the fear of no undo.

Which is exactly backwards, because undo is the entire point.

Git is undo for your whole project. Not a save button — a time machine. Every commit is a point you can stand at again. Once that lands, the tool stops being a threat and starts being a safety net. You experiment more, delete more boldly, rip things out, because you know, for a fact, that you can always get back.

I know the fear because I had it. My final-year project at university was the first time I had to use version control for real. Git, GitHub, not a clue what I was doing. I was so scared of breaking something I couldn't get back that I made myself small — tiny edits, one at a time, tiptoeing through my own code.

Then I learned to branch, and I never looked back.

A branch is a room you can make a mess in. You step off to the side of the working version, smash things around, and none of it touches what works until you decide it's ready. That's the flip — branching is permission to be reckless. The scared version of me tiptoed. Once I had branches, I stopped.

Every Git tutorial promises you safety and then buries it under fifty commands. But the safety is the pitch. You cannot lose your work, and everything else is detail. So here's the detail, stripped to what you actually touch day to day, in the order you meet it:

• git status: where am I? What's changed, what's staged, which branch I'm on.
• git add: choose what goes into the next save point.
• git commit: make the save point. Now you can always return here.
• git push / git pull: send your commits up to GitHub, pull everyone else's down.
• git branch / git checkout: open a room to make a mess in, and step between rooms.
• git merge: bring the good mess back into the working version.

That's eight commands. That's the whole daily job.

If you internalise only one of these, make it git status. Half the fear of Git is not knowing what state you're in, and status answers that every single time, before every commit and after every merge. You can't be scared of a room you can see.

Everything past these eight is recovery: undoing a commit you regret, backing out of a change you didn't mean to make, finding work you thought you'd lost. You don't need to memorise any of it. When I hit my first merge conflict on the job (two people's edits landing on the same lines, Git refusing to guess which one wins), it was daunting, and the thing that saved me wasn't the documentation. It was Oh Shit Git, a plain list of "here's the mess you're in, here's the exact command out." Keep it bookmarked. That's the whole strategy.

There's a plot twist I should be honest about. The same tools that lowered the floor can now do the Git for you, too. Ask Claude Code or Cursor to branch, commit, and push on your behalf and it happily will. So why learn any of this?

Because it will go wrong, and when it does, you'll be one more layer removed from the one skill that gets you out. The AI raised the floor on writing code; it quietly lowered it on understanding what you've actually got. A repository you can't read is a repository you can't recover, and recovery, remember, is the whole game. Let the AI drive if you want. Just make sure you can take the wheel.

Which brings me back to the title. In British English, a git is an annoying, unpleasant person. You know, the one who's a bit too much. I've spent this whole post asking you to become one.

Because here's what being a git actually looks like: you commit constantly. You branch without asking anyone's permission. You break things on purpose, because you know you can always walk it back. The scared version tiptoes through their own code. The git doesn't. Being a git just means being unafraid of your own tools.

So go on. Be a git.