Why Version Control Exists: A Short History of Git

Somewhere on your computer, right now, there is probably a folder that looks like this: project.zip, project_final.zip, project_final_v2.zip, project_final_v2_REALLY_final.zip. If you smiled just now, this series is for you.

That folder is version control. It's just the painful, do-it-by-hand kind. You kept old copies because you were afraid of losing something that used to work. You added REALLY_final because you'd been burned before. And if you ever emailed one of those zips to a friend, waited for their changes, and then spent an evening figuring out which file was the newest one — congratulations, you have personally re-lived the entire history of software development before the year 2005.

In this post there is nothing to install and nothing to type. It's a story — the story of why a tool called Git exists, and why every programmer on Earth uses it. Knowing the story makes the tool make sense.

The ancestors: files as library books

I started coding professionally in 1999, so I got to use the ancestors of Git firsthand. The first one I met was Microsoft's Visual SourceSafe, and it worked like a very strict library.

When you wanted to edit a file, you checked it out — exactly like a library book. And here's the part that sounds made up: while you had it checked out, nobody else could edit it. The file was locked. Read-only for the whole team.

Picture the scene. It's Monday morning, you need to fix one line in Billing.cs, and SourceSafe informs you that your colleague checked it out on Friday. Your colleague is now on vacation. For a week. I have watched grown developers walk to another desk, sit in someone else's chair, and check a file back in on their behalf — because that was easier than waiting.

One server to rule them all

The next generation, tools like Subversion (everyone called it SVN), fixed the locking problem. Several people could edit the same file, and the tool merged the changes together. That was genuinely wonderful, and for a few years we were all quite happy.

But SVN had one big design decision baked in: all the history — every version of every file, ever — lived on one central server. Your own computer held only the current snapshot. Want to see what a file looked like last month? Ask the server. Want to save your work as a new version? Ask the server.

So what happened when the server was down? Everything stopped. No saving versions, no looking at history, no comparing your changes. The whole team just… waited, refreshed, and went for chai. On a slow office network, even a normal day meant every operation took a little trip across the wire and back.

Centralized vs distributed, in plain words

That difference — where the history lives — is the big dividing line in version control. Here it is with no jargon:

Distributed means everyone carries the whole photo album, not just today's photo. Keep that image — we'll use it a lot in this series.

2005: the two weeks that changed everything

Now the drama. The Linux kernel — the heart of the operating system that runs most of the internet — is one of the largest collaborative projects ever, with thousands of contributors. For a few years its creator, Linus Torvalds, managed all those contributions with a tool called BitKeeper, which a company let the project use for free.

In April 2005, after a falling-out, that free arrangement ended. The world's most important open-source project suddenly had no version control it was happy with. Linus looked at the existing tools, decided none of them were fast enough or distributed enough, and did something outrageous: he sat down and wrote his own. The first working version of Git took him about two weeks. Within a couple of months, it was managing the Linux kernel.

Why Git won

Plenty of tools existed. Git took over the world for a few plain reasons:

• It's fast. Everything happens on your own disk, so saving a version or viewing history feels instant.
• It's distributed. The whole album is in your pocket. Work on a plane, on a train, with the Wi-Fi down.
• Branching doesn't hurt. In older tools, keeping a separate line of work was slow and scary. In Git it's so cheap you'll do it before lunch without thinking. (That's Part 4, and it's the best part.)
• Then GitHub made it social. In 2008, GitHub wrapped Git in a friendly website where anyone could share code, copy projects, and suggest changes. Git gave us the engine; GitHub gave it a town square.

Today the fight is simply over. The code for your phone's apps, your bank's website, the car you ride in, and very likely this page you're reading — effectively all of it lives in Git. Learning it isn't optional for a developer anymore, and happily, the beginner's portion is much smaller and friendlier than its reputation suggests.

What we'll do together

This is a workshop series, not a lecture series. From the next part onwards, you'll type every command yourself and watch what it does — we'll build a tiny repository of clinic notes from scratch, learn to read what Git tells us, and rescue ourselves from small mistakes. A few parts in, I'll hand you a real project: a small clinic application with a genuine history you can explore, branch, and break safely. It's waiting for you in a public repository, but we don't need it yet.

Enough history. In Part 2 we install Git, take our first "photo," and make you officially version controlled. Bring a folder; leave the zips behind.