The 3-Character Change That Saved GitHub: How Tom Preston-Werner Bet the Company on Git When Everyone Else Was Married to Subversion — And Won by Making Version Control Beautiful

The Bar Where the Future Was Forked

It was October 19, 2007. Tom Preston-Werner sat in a sports bar in San Francisco's Mission District, watching his co-founder Chris Wanstrath sketch diagrams on a napkin. Around them, Giants fans screamed at a baseball game. But Tom and Chris weren't watching baseball. They were trying to solve a problem that had plagued software developers since the 1970s: version control was hell.

Everyone used Subversion. SourceForge had 100,000 projects on it. Google Code had just launched. The enterprise world worshipped Perforce and ClearCase. And somewhere in the background, Linus Torvalds had built this weird, angry thing called Git that only kernel hackers could understand.

"What if," Chris said, drawing another box on the napkin, "we made Git... not suck?"

Tom laughed. Then he stopped laughing. Because Chris wasn't joking.

That napkin sketch would become GitHub. And in 10 years, it would be worth $7.5 billion when Microsoft bought it. But on that night in 2007, it was just two developers who were tired of Subversion's merge conflicts and Linus's contempt for people who didn't read man pages.

The Problem: Version Control Was a Punishment

In 2007, version control meant pain.

If you used Subversion (SVN), you lived in fear of the merge conflict. SVN used a centralized model — one server, one source of truth, and if two developers touched the same file, someone was going to spend their Friday afternoon resolving conflicts in XML files. Branching was technically possible but culturally forbidden. "Don't branch unless you absolutely have to" was the unofficial motto.

If you used CVS (Concurrent Versions System), it was worse. CVS couldn't even track file renames. Move a file? CVS thought you deleted one and created another. The entire history was gone.

And then there was Git.

Linus Torvalds built Git in 2005 after BitKeeper (the Linux kernel's version control system) revoked its free license. Linus was furious. He spent two weeks writing Git from scratch — a distributed version control system where every developer had the full repository history on their machine. No central server. No single point of failure. Branching and merging were instant and cheap.

It was brilliant. It was also completely unusable for anyone who wasn't Linus Torvalds.

The commands were cryptic: git rebase -i HEAD~3? git cherry-pick? git reflog? The error messages were hostile. The documentation assumed you had a PhD in graph theory. Developers who tried Git usually gave up and went back to Subversion within a week.

But Tom Preston-Werner and Chris Wanstrath saw something different. They saw that Git's distributed model was the future. They just needed to make it not feel like punishment.

The Bet: Build a Company on a Tool Nobody Wanted

Tom and Chris started building GitHub in their spare time. Tom was working at a consulting firm. Chris was at CNET. PJ Hyett, their third co-founder, joined from a startup. None of them quit their day jobs.

Their plan was insane: build a web interface for Git. Make it social. Make it pretty.

Everyone told them it was a terrible idea.

The Git community hated web interfaces. Linus himself had said Git was meant for the command line. Adding a GUI was "missing the point."

The enterprise was locked into Subversion. Companies had invested millions in SVN infrastructure. GitHub's pitch — "throw it all away and use this distributed thing" — sounded like startup fever.

VCs didn't get it. Version control wasn't sexy. SourceForge was free. Google Code was free. Why would developers pay for GitHub?

But Tom, Chris, and PJ kept building.

They launched a private beta in early 2008. The killer feature wasn't the UI. It was forking.

The Turning Point: The Fork Button That Changed Open Source

In Subversion, contributing to someone else's project was bureaucratic. You had to email the maintainer, ask for commit access, prove you were trustworthy, and then — maybe — you'd get permission to push code. Most contributions died in the email thread.

GitHub invented the Fork button.

You found a project you wanted to contribute to. You clicked "Fork." In three seconds, you had your own copy of the entire repository — full history, all branches, everything. You made your changes. You clicked "Pull Request." The maintainer reviewed your code in a beautiful diff view and merged it with one click.

No emails. No permissions. No waiting.

It was a 3-character change in how open source worked: SVN → Git. But the social implications were profound.

Suddenly, open source wasn't about begging for access. It was about forking and proving your worth through code. If a maintainer ignored your pull request, you could fork the project and build your own version. The best code won.

This was decentralized collaboration at the version control level. And developers loved it.

The Rails Moment That Proved It Could Work

In February 2008, GitHub launched publicly. Within a month, they had 2,000 users. Most were Ruby developers.

Then something happened that proved GitHub was more than a hosting service.

Rails core contributors started moving from Subversion to GitHub.

Rails — the most influential web framework of the 2000s — had been on SVN since 2004. But the core team was frustrated. Merging patches was slow. Reviewing contributions meant downloading patch files and applying them manually. It was a mess.

In April 2008, Rails officially moved to GitHub.

Overnight, GitHub became the de facto home for Ruby projects. Then Python. Then Node.js (when Node launched in 2009, Ryan Dahl put it on GitHub immediately). Then everything.

By 2009, GitHub had 100,000 users. By 2010, it had 1 million repositories.

SourceForge, which had spent a decade as the home of open source, suddenly looked ancient. Google Code shut down in 2016. Subversion became the punchline to jokes about legacy systems.

The Architecture: How GitHub Made Git Fast Enough to Feel Instant

Behind the pretty UI, GitHub had a serious technical challenge: how do you serve a million Git repositories without melting your servers?

Git's distributed model meant every git clone downloaded the entire repository history. For big projects (like the Linux kernel with 700,000 commits), that meant gigabytes of data. GitHub had to serve those clones to thousands of developers simultaneously.

Their solution was a custom Git infrastructure stack:

1. Smoke — The Distributed Git Server

GitHub built Smoke, a Git server layer that handled millions of concurrent connections. It used Unicorn (a Ruby HTTP server) to handle web requests, but the heavy lifting — serving Git data — was done by custom C code that talked directly to Git's object database.

Every git push and git pull went through Smoke, which sharded repositories across hundreds of servers. If you pushed code to a repo, Smoke routed it to the right machine, updated the refs, and propagated the change to read replicas.

2. Git Object Caching

GitHub cached Git objects (blobs, trees, commits) aggressively using Memcached. When you viewed a file on GitHub, the backend didn't read from disk — it hit Memcached first. Cache hit rates were above 90%.

For diffs, GitHub precomputed common comparisons (like master vs develop) and cached the results. This made pull requests feel instant even on repos with 100,000 commits.

3. The Merge Queue

GitHub's "Merge Pull Request" button looks simple. Behind the scenes, it triggers a complex workflow:

• Check if the branch is mergeable (no conflicts)
• Run CI tests (if configured)
• Perform the Git merge (using git merge --no-ff to preserve history)
• Push the result to the target branch
• Update all webhooks and integrations

All of this had to happen in under 2 seconds or users would click the button again, causing race conditions. GitHub built a merge queue using Resque (a Redis-backed job queue) that serialized merge operations per repository.

If two developers tried to merge simultaneously, the queue ensured the second merge didn't clobber the first.

4. The SQL Layer: How GitHub Tracked Millions of Repos

GitHub's metadata (users, repos, issues, pull requests) lived in MySQL. By 2011, they had billions of rows and were hitting scaling limits.

They solved it with horizontal sharding. Instead of one giant MySQL database, they split repos across multiple database clusters. Each cluster handled a subset of repositories, and a routing layer (github/github — their monolith Rails app) decided which cluster to query based on the repo ID.

They also built Trilogy, a MySQL client library designed for connection pooling and failover, which they open-sourced in 2022.

5. The Frontend: How GitHub Made Diffs Beautiful

The most important page on GitHub is the diff view. It had to be fast, readable, and handle files with 10,000+ lines.

GitHub's diff renderer used a custom algorithm based on Myers' diff algorithm (the same one used by git diff). But instead of showing raw text, they syntax-highlighted the code using Pygments (later replaced by TreeSitter for performance) and rendered it as HTML.

For massive diffs, GitHub implemented lazy loading — only the first 100 lines rendered immediately. Scroll down, and the next 100 lines loaded asynchronously. This made reviewing 5,000-line pull requests actually possible.

The Business Model: Freemium for Developers

GitHub's business model was simple: public repos are free, private repos cost money.

In 2008, a paid plan was $7/month for 5 private repos. Developers paid because GitHub was so much better than running their own Git server. Companies paid because their engineers demanded it.

By 2012, GitHub had 2 million users and was profitable without raising VC money. (They eventually raised $100M in 2012, but only because Andreessen Horowitz begged them.)

By 2018, GitHub had 31 million users and 100 million repositories. Microsoft bought it for $7.5 billion.

The Legacy: How GitHub Killed the Cathedral and Built the Bazaar

Before GitHub, open source followed Eric Raymond's "cathedral" model — centralized control, gatekeepers, permission-based contribution.

GitHub made the "bazaar" model the default. Anyone could fork. Anyone could contribute. The best ideas won through code, not politics.

Today:

• 90% of developers use Git (Stack Overflow survey)
• 100 million repositories live on GitHub
• Every major open source project (Linux, Kubernetes, TensorFlow, React, VS Code) is on GitHub
• Microsoft, Google, Facebook, Amazon host their open source work on GitHub

Subversion still exists, but it's a relic. SourceForge is a ghost town. And Git — the angry tool that Linus built in a rage-fueled weekend — is now the default way software is built.

Because three developers in San Francisco bet the company on making version control beautiful. And it turned out that developers, when given tools that don't fight them, will build extraordinary things.

The napkin from that sports bar is probably in a landfill somewhere. But the idea on it — that version control could be social, fast, and fun — changed how the world writes code.

All because of a Fork button. And a bet on Git when everyone else thought Subversion had already won.