Git is overwhelmingly the industry standard today, and GitHub the most widely used place to host it — but neither is the only option, and knowing what else exists helps make sense of an older codebase or a company using a different tool.
| Platform | Notable for |
|---|---|
| GitHub | The largest, most widely used — covered throughout this course |
| GitLab | Strong built-in CI/CD pipelines; also offers a fully self-hosted version companies can run on their own servers |
| Bitbucket | Tight integration with other Atlassian tools (Jira, Confluence) — common in teams already using those |
| Azure DevOps Repos | Integrated into Microsoft's broader Azure DevOps suite, common in enterprise .NET shops |
| SourceHut | A minimal, text-first alternative favored by some open-source projects that prefer email-based patches over pull requests |
All of these host Git repositories — everything from the earlier lessons (branches, commits, merges) works identically regardless of which one a project uses. The difference is entirely in the collaboration features layered on top (issues, CI/CD, project boards) and each platform's own interface.
| System | What it is | Where it's still found |
|---|---|---|
| Subversion (SVN) | Centralized (not distributed like Git) — one central server holds the only full history | Some older enterprise codebases, particularly pre-2010 projects |
| Mercurial (hg) | Distributed, conceptually similar to Git, with a reputation for a simpler command set | Facebook's internal monorepo historically used it; some open-source projects still do |
| Perforce (Helix Core) | Centralized, built for very large binary files (game assets, video) | Common in game development and other industries with huge non-text files Git handles poorly |
| CVS | One of the earliest widely-used systems, largely superseded | Occasionally in genuinely old, unmaintained projects |
Git's distributed model (every developer has the complete history, from the first lesson in this course) made branching and merging fast and cheap compared to the centralized tools that came before it — combined with GitHub's network effects, that's largely why Git become the default choice for the vast majority of new projects since around 2010.
The good news about all of this
None of these alternatives need to be learned in depth to work productively — the concepts from this entire course (commits, branches, merging, remotes) transfer directly, since Git borrowed and refined ideas that existed in some form in most of them.