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 retire-at-30-v2. Tomorrow there'll be a retire-at-30-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, the project’s primary branch. No feature branches and no review boundary. Every change lands directly on the version everyone else depends on and when main deploys automatically, those changes can go live immediately. 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. Once your work is committed, Git makes it incredibly difficult to lose. Everything else is detail. So here's the detail, stripped to what you actually touch day to day, in the order you meet it:

That's seven 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.

Most of what a beginner needs beyond these seven falls into two categories: understanding what happened and recovering when something goes wrong. That might mean undoing a commit you regret, backing out a change you did not intend to make, or finding work you thought you had lost. You do not need to memorise every command. When I hit my first merge conflict on the job, two people editing the same lines and Git refusing to guess which version should win... it was daunting. What helped me most was not the documentation, but Oh Shit Git, a plain list of "here's the mess you're in, here's the exact command out." I would say keep it bookmarked but now AI can generate you a cheatsheet and make it a whole lot prettier.

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. AI lowered the barrier to writing code but it also made it easier to avoid understanding what you have actually built. 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.