Types of Version Control Systems — Git, SVN, and the Rest
Git dominates version control today, but walk into a company and you may find a Subversion (SVN) repository alive and well. This article maps out the version control system (VCS) landscape and the conceptual differences between Git and SVN.
What is a version control system?
A system that records the history of file changes so you can trace "when, who, what, and why," and roll back to any point in time. It also acts as traffic control for parallel work, so multiple people can touch the same code without breaking it.
If you think of it as the official solution to the final_v2_fixed(latest).zip file-naming workflow, you are basically right.
Two models: centralized and distributed
Historically, VCSs evolved from "centralized" to "distributed."
| Centralized (SVN, etc.) | Distributed (Git, etc.) | |
|---|---|---|
| Where history lives | Only on the central server | Everyone has a full copy locally |
| What commit means | Applied to the central server immediately | Recorded only locally (share via push) |
| Offline work | Mostly impossible (even history needs the server) | Browse history, commit, branch — all offline |
| Revision identifiers | Sequential numbers (r100, r101, ...) | Hashes (a1b2c3d...) |
| Branches | Represented as directory copies; heavyweight culture | Lightweight; branch and throw away freely |
| If the server dies | History may be lost (backups are your only hope) | Restorable from anyone's clone |
- Centralized: one canonical copy in the middle; everyone commits directly to it. Simple to reason about, but you cannot work without a server connection
- Distributed: everyone holds a complete replica, works freely on their own copy, then synchronizes. The "central repository" on GitHub or GitLab is not a technical requirement — it is just how teams choose to operate (which is why commits complete entirely on your machine)
The major VCSs and where they are used
Git (distributed — today's de facto standard)
- Created by Linus Torvalds in 2005 for Linux kernel development
- Its weapons: lightweight branches, speed, fully offline operation. GitHub made it the OSS standard, and it became the industry standard from there
- There is almost no reason to pick anything other than Git for a new project
Subversion (SVN — the classic centralized VCS)
- The standard for corporate development in the 2000s. Still in production in long-lived internal systems
- It has properties Git lacks: easy-to-read sequential revisions, checking out only a subdirectory of the repository, and file locking (forbidding concurrent edits)
- For repositories full of huge binaries, a centralized system that does not copy all history to every machine can actually be lighter — some shops keep SVN deliberately for this reason
Mercurial (distributed)
- A distributed VCS born around the same time as Git, with a cleaner command set; Facebook and Mozilla once used it
- New adoption has essentially stopped, and its main hosting (Bitbucket) ended support. It is enough to know it as "the other distributed VCS that lost to Git"
Perforce (Helix Core — centralized)
- A commercial VCS that is strong in game studios and anywhere with massive binary assets. Fast even with hundreds of GB of assets, and its file-locking workflow fits art production well
- Still first-string for large Unreal Engine projects
Git vs SVN translation table
A cheat sheet for when you land in an SVN shop. The trap: some words are the same but mean different things.
| What you want to do | SVN | Git |
|---|---|---|
| Get the repo locally | svn checkout URL (gets a working copy only) |
git clone URL (replicates full history) |
| Pull in the latest | svn update |
git pull |
| Record a change | svn commit (hits the server immediately) |
git commit (local only) → share with git push |
| Check status | svn status |
git status |
| Diff | svn diff |
git diff |
| History | svn log |
git log |
| Undo changes | svn revert |
git restore and friends |
| Branch | svn copy (copy into a branches/ directory) |
git branch / git switch -c |
| Standard layout | trunk/ branches/ tags/ directories |
main branch + branch feature |
Differences to watch out for:
checkoutmeans completely different things. SVN's checkout is Git's clone. Git's checkout (switch) changes branches- SVN's commit is shared instantly. Commit casually with Git instincts and your non-building code lands on the whole team immediately. In SVN, think "commit = push" and be careful
- SVN has no staging area (
git add). Every modified file is a commit candidate as-is - SVN branches are copy-based, so many teams do not have Git's "one branch per feature, several per day" culture. Follow the local rules
Which one should you learn?
- Git is all you need. Once you internalize the concepts (distributed model, branching, merging), other VCSs are just a translation-table exercise
- If you join an SVN shop, start with the table above plus two rules: "commit is shared instantly" and "checkout means clone"
- The
git svnbridge lets you treat an SVN repository as Git locally (if your team's rules allow it)
Summary
- VCSs come in two models: centralized (one history in the middle) and distributed (everyone holds a full replica)
- Git (distributed) is today's default. SVN survives in legacy corporate repos; Perforce rules games and large binary assets
- The biggest Git-vs-SVN trap: checkout and commit mean different things. SVN's commit hits the server immediately
- Learning priority is Git, full stop. Translate on the fly for anything else you encounter