## The Origin Story: When Linus Torvalds Got Mad

In April 2005, Linus Torvalds had a problem. He was managing the Linux kernel, one of the most complex software projects in the world, with contributions from developers across dozens of countries. The version control system they’d been using, a proprietary tool called BitKeeper, suddenly revoked its free license.

BitKeeper had been a compromise. Torvalds didn’t love it, but it was better than the alternatives. When the license was pulled (over a dispute about someone reverse-engineering BitKeeper’s protocols), the Linux kernel project was left without a way to manage thousands of code changes from hundreds of contributors.

Torvalds looked at the existing free version control systems. None of them met his needs. So on April 7, 2005, he made the first commit to a new system he’d started writing himself. He called it Git.

Ten days later, Git was self-hosting. The Linux kernel project was using Git to manage Git’s own development. By July, Torvalds handed maintenance over to Junio Hamano, who released version 1.0 in December.

The lesson here isn’t just that Torvalds is fast (though he is). It’s that when existing tools don’t solve the problem you actually have, building your own is often simpler than you think. Git wasn’t trying to be everything to everyone. It was trying to solve one specific problem: distributed version control for a large, distributed team. And it did that exceptionally well.

## What Git Actually Does (And Why It Matters)

If you’re reading this, you probably already know what version control is. But let’s be explicit about what makes Git different, because the differences matter.

Every copy is the real copy. Git is distributed. When you clone a repository, you get the entire history, not just the current files. You can work offline. You can branch, merge, and commit without asking permission from a central server. The “remote” repository (the one on GitHub, or Forgejo, or wherever) is just another copy. Important, yes, but not fundamentally different from yours.

Remotes are for backup and coordination, not permission. A remote repository in the cloud (or self-hosted) serves two purposes. First, it’s your backup. If your laptop dies, the code is safe. Second, it’s where you coordinate with other developers. You push changes up, they pull them down, you merge. But the remote doesn’t own your work. You do.

Branching is cheap and safe. Before Git, branching was something you thought carefully about because it was expensive. Git made branching so lightweight that the recommended workflow is to branch constantly. Try something. Doesn’t work? Delete the branch. It costs nothing.

This is how I use it daily: I work on my office computer with multiple monitors when I’m at my desk. When I’m traveling, I work on my laptop. Git keeps both in sync. I push from the office, pull on the laptop, make changes there, push again, and pull back at the office. It’s seamless. The code follows me. That alone is worth the setup.

## GitHub: The Platform That Made Git Mainstream (Then Got Acquired)

Git existed, and it was powerful, but it wasn’t friendly. GitHub, launched in 2008, made Git accessible. They added a web interface, pull requests, issue tracking, and a social layer that turned coding into something you could watch happen.

I used GitHub extensively when I was teaching. Private repositories for students, automated builds, managing tickets, coordinating workflow for teams. Did I have to rig some things to get private repos working the way I needed? Yes. But it worked, and it worked well.

GitHub also gamified contributions. Those little green squares on your profile showing your commit history? The badges and streaks? I’ll admit it: I liked them. I wasn’t chasing badges. I was using Git for what I needed, but the visual feedback was oddly satisfying. It made the work feel visible.

Then Microsoft bought GitHub in 2018 for $7.5 billion. The acquisition was completed in October of that year, and suddenly the world’s largest code hosting platform was owned by a company with a complicated history in open source.

To Microsoft’s credit, they haven’t ruined GitHub. It’s still broadly useful, and I still use it (here’s my repo if you want to see). But the acquisition reminded everyone of something important: when your code lives on someone else’s platform, that platform can change ownership, change terms, or change direction without asking you.

## The Gitea-to-Forgejo Story: When Open Source Goes Corporate

Around the same time people were nervous about Microsoft owning GitHub, a lighter-weight alternative called Gitea was gaining traction. Gitea was open source, self-hosted, and fast. A perfect option for developers who wanted the convenience of a GitHub-style interface without handing their code to a corporation.

Then in October 2022, the Gitea project did the thing that always worries people in open source: the trademark and domain were quietly transferred to a newly incorporated for-profit company, Gitea Limited. The contributors weren’t consulted. The governance structure changed overnight. The fear was that Gitea would adopt an “open-core” model, where the community edition stays free but important features get held back for the paid version.

Several long-time Gitea maintainers objected. Within weeks, they forked the project and called it Forgejo (pronounced “for-jay-oh”). Forgejo is managed by Codeberg e.V., a German non-profit, and its governance structure is designed to prevent exactly the kind of corporate takeover that spooked the Gitea community.

At first, Forgejo was a “soft fork”. It contained all of Gitea, with small additions. But in early 2024, Forgejo became a “hard fork,” meaning its codebase began to diverge. In April 2024, Forgejo released version 7.0 with its own roadmap and features.

This is where I’ve been moving more of my own work. Not because GitHub is bad or because Gitea is evil. Both are fine tools. But Forgejo is self-hosted, controlled by a non-profit, and structurally insulated from the kind of incentive shifts that come when investors or acquirers show up.

## Why Version Control Is About More Than Code

Here’s what Git gives you, beyond the obvious “track your changes” pitch:

History you can trust. Every commit is a snapshot. You can go back to any point and see exactly what the code looked like. Not a backup. An exact recreation. This is invaluable when something breaks and you need to know what changed.

Collaboration without chaos. Multiple people can work on the same project without stepping on each other. Git handles the merging. When conflicts happen, Git shows you exactly where, so you can resolve them deliberately.

Freedom to experiment. Branching is so cheap that trying something risky costs nothing. If it works, merge it. If it doesn’t, delete the branch and move on.

Portability. Your repository isn’t locked to one platform. You can move it from GitHub to Forgejo to a bare server in your closet. The history comes with you. The tools don’t change.

This last point matters more than people realize. If you’ve ever tried to export data from a proprietary system (a CRM, a project management tool, a booking platform), you know how painful it is. Git repositories are just files. You own them completely. They go where you go.

## What About the Alternatives?

Git isn’t the only version control system. It’s worth knowing what else exists, even if you never use them.

Subversion (SVN): The previous generation’s tool. Centralized, not distributed. Still used in some enterprise environments, but Git has mostly replaced it.

Mercurial: A distributed system like Git, released around the same time. Slightly easier to learn, slightly less powerful. Some big projects used it (Facebook, Mozilla), but Git won the mindshare war.

Perforce: Used in industries like gaming where files are enormous (textures, models, binaries). Git struggles with very large files; Perforce handles them well. If you’re shipping a game with gigabytes of assets, Perforce might be the right tool. For code, Git is simpler.

Most developers will never need to learn anything but Git. The ecosystem has settled.

## Self-Hosted Git: Forgejo, Gitea, and Bare Repositories

If you want to host your own Git server, you have options.

Forgejo or Gitea: Full GitHub-style interfaces with pull requests, issue tracking, user management, and web-based code browsing. Forgejo is the fork committed to staying non-profit and community-run. Both are lightweight. They’ll run on a modest VPS for a few dollars a month.

A bare Git repository on your own server: If you don’t need a web interface and just want a remote backup, you can set up a bare repository on any server with SSH access. It’s just files. git push works the same way. This is the simplest option if you’re comfortable on the command line.

Hosting providers that aren’t GitHub: Codeberg (which runs Forgejo), GitLab (self-hosted or their hosted service), SourceHut, and others. Each has trade-offs, but all of them give you more control than leaving everything on a platform owned by a tech giant.

I’ve been moving more toward Forgejo because it aligns with how I think about tools: open source, non-profit governed, self-hosted when possible, and free of the incentive structures that push platforms toward rent-seeking and lock-in.

## The Real Lesson

Linus Torvalds built Git because he needed better version control for Linux. He didn’t ask permission, didn’t wait for someone else to solve it, and didn’t settle for tools that almost worked. Ten days later, he had something that worked exactly the way he needed.

You don’t have to be Linus Torvalds to benefit from that mindset. Git exists now. The hard work is done. What remains is choosing where your code lives and who controls it.

You can keep everything on GitHub and trust that Microsoft’s incentives stay aligned with yours. That’s a reasonable choice. Or you can self-host on Forgejo and know that the platform can’t change terms, raise prices, or sell to someone else because you’re the one running it.

The tools are there. The code is portable. The choice is yours.

## Learn More

• Git official site: https://git-scm.com/ (documentation, downloads, and the complete Git book)
• Forgejo homepage: https://forgejo.org/ (self-hosted, non-profit governed Git hosting)
• Codeberg: https://codeberg.org/ (a public Forgejo instance, free to use, run by a non-profit)
• GitHub’s history with Git: https://github.blog/open-source/git/git-turns-20-a-qa-with-linus-torvalds/ (interview with Linus Torvalds on Git’s 20th anniversary)
• The Forgejo fork story: https://forgejo.org/2024-02-forking-forward/ (why the project forked from Gitea and what it means)
• My GitHub profile: https://github.com/JudyLipinski (see how I use Git in practice)