Version control systems are the memory of a software project. They record every change, who made it and why, and they can pull any earlier version back in seconds. This guide explains how they work, how the two families differ, and why one tool, Git, ended up running almost everything.
Version control systems are programs that record the changes made to a set of files over time. Each time a developer finishes a meaningful step of work, the system stores a snapshot of the files, notes who made the change and when, and keeps a short message that explains why. Weeks or years later, the team can open any snapshot, compare it with any other snapshot, or roll the whole project back to it.
That sounds like bookkeeping, and it is, but it covers the scariest moments in software. A change breaks the app at midnight and nobody knows which change did it. Two people edit the same file on the same morning and one silently overwrites the other. A client asks for the exact version from last March. Version control systems answer all three without panic, which is why professional teams treat them as basic equipment, in the same class as the editor and the compiler.
| Version control at a glance | |
|---|---|
| Core job | Record every change to a project’s files, with the author, the date and the reason attached |
| The two families | Centralized: one server holds the history. Distributed: every working copy holds the full history |
| Most used system | Git, created in 2005 by Linus Torvalds for the Linux kernel |
| Other names | Source control, source code management (SCM) and revision control all mean the same idea |
| Works on | Code first, but also documents, designs, configuration files and anything else that changes over time |
The mess that version control ends
Without a system, teams track versions with file names. The shared drive fills with report-final.docx, report-final-v2.docx and the desperate report-final-REAL.docx, and nobody can say with confidence which one the client approved. Programmers do the same thing with whole folders, copying project-backup-monday next to project-backup-tuesday until the copies eat the disk and nobody trusts any of them.
The real damage is quieter. A developer fixes a bug on Monday. On Wednesday a teammate uploads an older copy of the same file and the fix vanishes, with no record that it ever existed. The bug returns, users report it again, and the team cannot prove when it came back or why. Or a change ships on Friday and breaks the checkout. With no recorded history, the hunt for the bad change runs on memory and guesswork across thousands of lines.
Version control replaces that chaos with one rule: work goes into the record in small steps, with names and notes attached. The question “who changed this line, and what were they trying to do?” always has an answer, because the system wrote it down at the moment the change happened.
The six words every system shares
Different tools use slightly different commands, but all version control systems speak the same six words. Learn these, and every tool in this field starts to look familiar.
| Word | What it means | In plain terms |
|---|---|---|
| Repository | The project’s home: the files plus their entire recorded history | One repository per project, usually shortened to “the repo” |
| Commit | A saved snapshot of your changes, with your name, the date and a note on why | “Fix the login timeout” stored as one commit |
| Branch | A separate line of work that splits off, so you can change things without touching the main version | A branch called new-checkout, built for one risky redesign |
| Merge | Folding one branch’s changes back into another, usually into the main line | The finished new-checkout branch merges into main |
| Conflict | What happens when two people change the same lines in different ways and the system refuses to guess | You and a teammate both rewrite the same paragraph, so a person picks the winner |
| Remote | A copy of the repository stored somewhere else, such as a company server or a hosting service, that you sync with | You push your commits to the remote, and teammates pull them down |
Branches deserve a special mention, because they change how people work. A branch costs almost nothing in a modern distributed system, so developers split one off for nearly every idea. A branch is where risky work belongs: rebuild the checkout, test a new library, try the design the team argued about all week. It works like rapid prototyping for code. If the idea proves itself, it merges into main. If it flops, the team deletes the branch, and the main line never noticed a thing.
The two families: centralized and distributed
Version control systems come in two families, and one question separates them: where does the history live?
In a centralized system, a single server holds the only complete history. Developers check out the current files, edit them, and commit their work back to that server. Subversion and Perforce work this way, and so did CVS, the system many older teams started on. The model is easy to picture and easy for administrators to control, since one place means one set of permissions. It also carries one famous weakness: the server is a single point of failure. If it goes down for an hour, nobody can commit, browse history or compare versions until it returns. If its disk dies without good backups, the entire history dies with it.
In a distributed system, every developer clones the whole repository, full history included. Committing, browsing old versions and comparing changes all happen on your own machine, at full speed, with no network connection at all. You sync with a shared copy when you are ready. Git and Mercurial work this way, and the design removes the old weakness: if the shared server is wiped out, any team member’s clone can restore it, because every clone is a complete backup of the project.
An older third style came before both: local version control, which kept the history on one person’s machine and never shared it. Tools such as RCS served lone programmers well for years. Teamwork outgrew them, and the family split above is the one that matters when you choose a system today. The free Pro Git book walks through all three generations with diagrams, and it stays the clearest short history of the field.
| Question | Centralized | Distributed |
|---|---|---|
| Where the history lives | On one central server | In every clone of the repository |
| Working offline | Mostly no: committing needs the server | Yes: commit and browse history on your own machine |
| Speed of daily work | Depends on the network | Fast, because most actions never leave your machine |
| If the main copy is lost | The history is gone with it | Any clone can restore the whole project |
| Examples | Subversion, Perforce, CVS | Git, Mercurial |
Neither family is a museum piece. Plenty of companies still run centralized systems in production today, and the sections below show where each tool in this field earns its keep.
Git: the tool that took over
Git began in a fight. For several years the Linux kernel, one of the largest open source projects in the world, tracked its code with a commercial tool called BitKeeper. In 2005 the arrangement behind that deal broke down, and the kernel team’s free access ended. Rather than shop for a replacement, Linus Torvalds, the creator of Linux, built one. His goals were blunt: speed, a simple design, strong support for non-linear development across thousands of parallel branches, a fully distributed model, and the strength to handle a project as large as the kernel itself, efficiently.
Git hit those goals, and then two forces carried it everywhere. Cheap branching made the branch-per-idea habit normal, because a branch in Git is a lightweight pointer instead of a heavy copy of the project. And hosting services, covered in the next section, made sharing a Git project nearly effortless. The result is the closest thing software has to a standard tool. In Stack Overflow’s 2022 Developer Survey, more than nine in ten respondents named Git as a system they use, while Subversion sat near 6 percent and Mercurial near 1 percent. Among modern version control systems, nothing else comes close.
Git is not gentle at first. Its commands carry two decades of design decisions, and beginners meet cryptic messages early. Teams accept the learning curve because the skill transfers to almost any job in software. Employers expect it, interviewers ask about it, and Git practice sits on most preparation checklists right beside the classics in our roundup of the best coding interview books.
The other systems still earn their keep
Subversion is the elder statesman. CollabNet founded the project in 2000, it later became a project of the Apache Software Foundation, and its pitch was always simplicity: one server, revisions numbered in a clean sequence, a model a new hire can learn in an afternoon. The project is alive. The Apache team shipped Subversion 1.15 in October 2026, and the Apache Subversion project site still describes the tool, in its own words, as enterprise-class centralized version control. Companies holding decades of history in a Subversion repository often have no reason strong enough to move it.
Mercurial tells a sadder story. Developer Matt Mackall announced it in April 2005, days after work on Git began, in response to the same BitKeeper breakdown. Many developers found its commands calmer and more consistent than Git’s, it is written mostly in Python, and large projects adopted it. You can still read its pitch on Mercurial’s own site: a free, distributed tool where every clone contains the whole history. But the network effect won. Bitbucket, the hosting service that began life in 2008 as a Mercurial-only host, removed Mercurial support in 2020 after new users stopped choosing it. Mercurial still works, and it still has devoted users, but new teams rarely meet it.
Perforce P4, sold for years under the name Helix Core, holds a different fort. It is a commercial centralized system built to move very large files quickly, and game development runs on very large files: art, audio, video and compiled builds that can weigh gigabytes each. On Perforce’s own product page, the company calls P4 the industry standard version control platform for game development and says 19 of the top 20 AAA game studios use it. Whatever the exact count, game, film and hardware teams remain its home ground, a world where Git, designed around text files, strains under the weight of binary assets.
Git is not GitHub: the hosting layer
One confusion survives every beginner course: Git and GitHub are not the same thing. Git is the free tool that runs on your machine and tracks your files. GitHub is a company that stores Git repositories online and builds teamwork features around them. GitLab and Bitbucket do the same job for the same kinds of teams, each with its own mix of free and paid plans. Version control systems can all live on a server somewhere; Git simply has the largest hosting world built around it.
What the host adds is process. A pull request, called a merge request on some services, is a formal proposal: here are my commits, review them, discuss them, and only then merge them into the main line. Around that proposal sit line-by-line review comments, issue trackers that keep bugs and tasks beside the code, and automation that runs the test suite on every push. None of that lives inside Git itself. Git keeps the history. The host organizes the conversation about the history.
Which system should you choose?
For a new project, the honest default among version control systems is Git. It is free and open source, every hosting service supports it, every developer you hire will already know it, and help for any problem you hit sits one search away. Choose it unless a specific fact about your project argues otherwise, and learn its small set of daily commands well instead of collecting rare commands you will never run.
The exceptions are real. A game or film team shipping huge binary assets should look hard at Perforce. A company that inherits a healthy Subversion setup can keep it and sleep fine. And whatever you choose, two habits matter more than the tool: commit in small steps with messages that explain why, and agree as a team on how branches get reviewed and merged.
Two modern pressures make those habits urgent. AI coding assistants can now rewrite a file in seconds, and version control is the safety net that lets you review what they changed, line by line, and undo it when they are confidently wrong; our tests of the best AI coding assistants show both the speed and the mistakes. And as a project grows, the structure inside the repository matters as much as the tool around it, which is exactly the problem that feature sliced design tackles for frontend code.
Conclusion
Version control systems give a project a memory. They record what changed, who changed it and why, and they let a team rewind any mistake instead of rebuilding from guesswork. The families split on one question, where the history lives, and history itself picked a winner: Git, born from the Linux kernel’s emergency in 2005, now sits under almost every project a developer will ever join. Learn the six shared words (repository, commit, branch, merge, conflict and remote), and you can walk into any team, on any system, and read the record like you were there.
Frequently asked questions
What is the most used version control system?
Git, by a wide margin. Linus Torvalds created it in 2005 to track the Linux kernel, and in Stack Overflow’s 2022 Developer Survey more than nine in ten respondents named Git as a version control system they use. Subversion and Mercurial followed in the low single digits.
What is the difference between centralized and distributed version control?
In a centralized system, one server holds the only complete history, and developers check files out from it and commit back to it. In a distributed system, every developer keeps a full copy of the repository and its history, works locally, and syncs with others when ready.
Is Git the same as GitHub?
No. Git is the free version control tool that runs on your own computer and records your project’s history. GitHub is a hosting service that stores Git repositories online and adds teamwork features such as pull requests, code review and issue tracking. GitLab and Bitbucket do the same job.
Written by
Ahmad Jajja
Ahmad covers AI, chips and the companies behind them. For this guide he went back to the primary sources: the Pro Git book and the project sites of Subversion, Mercurial and Perforce.
Reviewed by
Danish Mustafa
Danish reviews laptops, phones and home tech over weeks of real use, and fact-checks the numbers in our AI coverage. He verified every date and survey figure in this guide against the page it came from.