Why Use Git When Nobody Else Touches Your Code

"A zip file does that."

That was my answer, years ago, when a manager at the university where I worked asked me to take a look at GitHub. I looked. I found it complicated in a way I couldn't justify, built for problems I didn't have, and I said so. If I wanted a copy of my work, I could make a copy of my work.

I was right.

Most answers to why use git skip the part that made me right, so I will start there. I was not writing code.

The objection was good. It expired.

I was in IT, not development. I supported systems, I did not build them. What little I wrote for myself fit in one file and got edited twice a year. For work like that, a dated zip on a network share is not a poor version control system. It is a reasonable one.

The objection I made then is the one I hear now from people building with AI, almost word for word. I work alone. Nobody else is touching this. What is version control protecting me from?

The answer is you. It was always going to be you.

What changed was not git. It was how fast code started arriving. Once I got past knowing what a variable is and realized the AI could do more than autocomplete, I started building an iOS app. I have not finished it. I still intend to. But the code on my machine got past the point where I could hold it in my head, and it was changing several times a day.

A zip file gives you one moment. It gives you the moment you remembered to make it.

So I asked the AI to explain GitHub. It did something I did not appreciate at the time: it started with git, and got to GitHub second. Then I asked whether we could use it and whether it could run it for me. It said yes.

Not with a tutorial, and not really with a decision. I asked a question and handed the answer to something else to operate.

What version control actually is

A backup is a copy of your work as it was at one moment. Version control is a copy of your work at every moment you marked, with the differences between any two of them, labeled and searchable.

Think of git as a backup and you will use it as a backup: save once a week, never look at the history, throw away the part that actually saves you.

It is a backup you can walk backwards through. It is what turns a rollback into something you can perform rather than something you wish you had set up.

Two words carry most of the weight. A commit is a point you marked, with a note saying what changed. A repository is a project folder that git is watching. Enough to start with.

Where git came from, and why it feels like too much

Git was written in 2005 by Linus Torvalds and the Linux kernel community. Until then the kernel had been developed with BitKeeper, a proprietary system, since 2002. That year the arrangement broke down and BitKeeper's free-of-charge status was revoked. The community needed a replacement and built their own.

The stated design goals are worth reading if git has ever made you feel slow. Speed. Simple design. Strong support for non-linear development, with thousands of parallel branches. Fully distributed. Able to handle a project the size of the Linux kernel efficiently.

Read that third one again. Thousands of parallel branches.

Git feels like overkill for keeping track of a browser extension because it is. It was built for one of the largest software projects on earth, worked on by thousands of people. You need perhaps a fifth of it.

Nobody says this to beginners, and it is what would help most. What stops people is not that git is hard. It is the suspicion that they are supposed to understand all of it.

Git is not GitHub, and I learned that the expensive way

Git is the thing on your machine. GitHub is a place that keeps a copy of it. That is the whole distinction, it was the first thing the AI told me, and I did not own it until it cost me something.

I was doing routine file cleanup on my laptop and I deleted a folder. It was the folder with my code in it. A dumb mistake. I was moving fast and not paying attention.

I ran an undelete and it worked, or it looked like it worked. When I had the AI look at the project again it told me something was wrong and gave me a reason. I did not understand the reason at the time, which is its own small lesson about vocabulary.

Here is what I have since worked out. Git keeps a project's entire history on your local disk, in a directory called .git, and that directory sits inside the project folder. Not beside it. Inside it. The name begins with a dot, which means anything that hides dot-files by default hides it from you too, including the Finder. So the undelete handed me back files. It did not hand me back the history, because the history was inside the thing I had deleted.

I was traveling, so my Time Machine drive was at home and no use to anyone.

What I typed next was: can we get it from git.

That was the wrong word and I had no idea it was the wrong word. Git was gone. Git had been in the folder. What answered was GitHub, which had a copy because I had been pushing to it, and it came back quickly and correct.

I could not tell you which of the two I thought I was asking for. It does not matter, because only one of them could have worked. That is the entire distinction, delivered by a mistake, long after somebody explained it to me on day one.

Why use git when you work alone

Four honest answers, and the fourth is the one nobody gives you.

1. It is the only undo that survives your own mistakes. Editor undo dies when you close the editor. A zip file dies with the drive it sits on. A pushed commit does not care what you do to your laptop.
2. It is the default everywhere. Every tool, tutorial, hosting service and AI assistant assumes you have it. Working without it means working against the current of everything else you touch.
3. It is how you share when you have to, and you may have to. Publishing something, asking for help with one file, handing a project to somebody who needs to see it.
4. Most of the pressure to use it comes from a professional team context that does not apply to you. Branches, pull requests, merge conflicts, code review. That is where the noise comes from, and why it all reads like homework somebody else assigned. It is not for you. You can skip it for now.

The fourth is why I turned it down the first time and why it took me years to come back. Nobody separated the part I needed from the part built for a thousand kernel developers.

How little of it you actually need

Here is my entire practice, and I type none of it.

At the end of a coding session the code gets committed and pushed. That is fixed, whether or not the session went well. The bad sessions are the ones where it matters most. During a session, if the AI thinks something is worth saving, it proposes a commit and waits for me to say yes.

That second half is the part I would argue for. In an earlier post I made the point that letting the AI manage your commits puts your safety net in the hands of the thing you are protecting yourself from. The approval step is what I did about it. I am not typing the commands and I do not plan to start. But nothing gets marked as a safe point unless I agreed it was one.

That is it. Commit, push, and a rule about when. I have used the history exactly once, and once was enough to pay for everything it ever cost me to learn.

GitHub's free plan includes unlimited private repositories, so the copy-somewhere-else half costs nothing and nobody has to see your code. That was the other thing I did not know when I said no.

Guardrail #9 · Commit at the end of every session, and make the AI ask.

Give it a standing rule: when the session ends, the code gets committed and pushed. Any time it thinks something is worth saving, it proposes the commit and waits for your approval. You are not typing the commands. You are the approval step, and a safe point nobody agreed to is not a safe point.

If you are building with AI and none of this is set up, the smallest useful version takes ten minutes. Ask your assistant to put the project under version control and push it somewhere you can reach from another machine. Then ask the question I did not know to ask: where does the history live, and what happens to it if I delete this folder.

Next in this series: the daily loop. Commit, push, pull, clone, what a commit actually is, and when to make one, which for anyone building with AI means before you let it loose.

Receipts

• A Short History of Git · official Git documentation: the 2005 origin, BitKeeper, and the design goals.
• What is Git? · official Git documentation: snapshots, and history living on your local disk.
• Git Internals: Git Objects · official Git documentation: where the .git directory sits.
• git-push · official Git documentation: what pushing to a remote does.
• About repositories · GitHub Docs: GitHub's own definition of a repository.
• GitHub's plans · GitHub Docs: the free plan and unlimited private repositories.