Most people meet version control the hard way, usually through a folder full of files named final\_v2 and final\_v2\_REAL, with no clear idea which one is current. A version control system swaps that mess for a tracked history of every change, including who made it.
It also goes by revision control or source code management. Git, Subversion and Mercurial are the best-known tools, and they handle source code, though designs and documents can be tracked the same way.
None of this is new. A 1975 paper in IEEE Transactions on Software Engineering already described a Bell Labs tool that recorded who changed a file, when, and why. That puts the idea about three decades ahead of Git.
What Is Version Control?
Every change to a set of files gets recorded as a history you can walk back through. Contributors can compare versions, restore an earlier state, and merge parallel work without overwriting each other.
Source code is the usual target, but any file type works. The Pro Git book points out that a designer can track every version of an image or layout the same way.
Revision control and source code management are the other common names. In daily conversation, teams usually shorten it to source control.
It helps to separate it from a backup. A backup keeps a copy of your files at one moment, while version control keeps every change, plus who made it, when, and why.
Version control is the practice, and Git is one specific tool for it, first released in 2005. GitHub is something else again, a hosting service for Git repositories.
People mix these up constantly. A short read on how Git differs from GitHub clears up most of the confusion.
What Problems Does Version Control Solve?
The oldest problem is two people editing the same file, where whatever gets saved last wins. A tracked system keeps both versions and flags the clash so someone can merge them.
History matters just as much. A bad change at 5 p.m. turns into a quick rollback instead of an evening of retyping, and Pro Git notes you can send selected files, or the whole project, back to an earlier state.
Every commit also carries an author, a timestamp and a message. Finding who introduced a bug, and when, takes a minute instead of a meeting.
Then there’s parallel work. Branches let several people change the same codebase at once and combine the results later.
Doing all this by hand falls apart quickly, since nobody can say which copy is current.
Solo projects benefit too. A history answers “what did I change last Tuesday” faster than memory does, which is reason enough for me to use it on a project nobody else touches.
How Does Version Control Work?
Changes live in a repository. You edit files in a working directory, pick the edits worth keeping, and commit them. Each commit saves a snapshot under a unique ID, tagged with who made it and when, plus a message, so any earlier state can be recalled.
The Commit Cycle
Files you edit on disk sit in the working directory. Edits chosen for the next commit go into the staging area, and the repository is the database that holds every committed version with its metadata.
Git adds that middle step, called staging, which keeps a commit limited to related edits. Other systems skip it and commit straight from the working copy.
Git identifies each commit with a 40-character SHA-1 commit hash calculated from content. According to Pro Git, that checksum is how Git notices corruption.
Snapshots vs Deltas
Delta-based tools store a base file plus the changes between versions. Pro Git puts CVS, Subversion and Perforce in that group, and RCS works through patch sets. Git goes the other way and stores the state of every file at each commit, with unchanged files pointing back to the copy already stored.
The split is more conceptual than physical. Git writes loose objects first, then packs similar files into deltas when it runs garbage collection, pushes to a remote, or piles up too many loose objects.
In the Pro Git packfile example, objects totaling about 15K shrank to a 7K packfile after one git gc run. The newest file version stays whole and the older one becomes a delta, because the latest version is needed fastest.
Core Operations
| Operation | What it does | Typical use |
|---|---|---|
| Diff | Shows line-level differences between two versions | Review a change before committing |
| Revert | Returns a file or the whole project to an earlier state | Undo a bad change |
| Tag | Names one specific commit | Mark a release |
| Branch | Opens a parallel line of work | Build a feature in isolation |
| Merge | Combines branches into one history | Ship finished work |
Most systems also offer a blame or annotate view that shows who last touched each line.
What Are the Types of Version Control Systems?
What separates them is where the history lives. Local systems keep it on a single machine, and centralized systems move it to a server. Distributed systems are the odd ones out, since every contributor gets a full copy.
| Feature | Local | Centralized | Distributed |
|---|---|---|---|
| Where history lives | One machine’s disk | One shared server | Every clone |
| Offline commits | Yes | No | Yes |
| Collaboration | None built in | Through the server | Push and pull between repositories |
| Example tools | RCS | CVS, Subversion, Perforce | Git, Mercurial |
RCS is the classic local system. Pro Git says it still ships with many computers, and it keeps patch sets in a special format on disk.
In a centralized setup, a single server holds every versioned file and clients check files out of it. Pro Git lists CVS, Subversion and Perforce as the standard examples.
Permissions and oversight sit in one place, which admins like. The catch is that commits need a network connection, so server downtime blocks everyone.
Subversion started at CollabNet in 2000 as an open-source system modeled on CVS, per the Apache Software Foundation’s 20th anniversary announcement. As of February 2020, the ASF still ran its own infrastructure on it, with more than 1.8 million commits across 300 top-level projects and sub-projects (The Register).
Distributed systems work differently. Every clone mirrors the full repository, history included, and nearly every operation runs locally, so browsing history or committing on a train works without a connection.
Contributors still sync through a shared remote repository, but daily work never depends on it. If that server dies, any clone can restore it, as Pro Git describes.
The Linux kernel is the best-known case. After BitKeeper’s free-of-charge status was revoked in 2005, the kernel community built Git to be fast, fully distributed, and able to handle large projects (Pro Git).
Which Version Control System Should You Choose?
Git is the default answer unless a specific constraint points elsewhere. Subversion suits teams that want a centralized model, and Mercurial suits teams already running it. Large binary assets point toward Perforce P4 (formerly Helix Core) or Plastic SCM.
The usage numbers show how lopsided the field is. 96% of professional developers use Git (Stack Overflow Developer Survey 2022, cited on git-scm.com). On the hosting side, 81.1% of all respondents use GitHub for code documentation and collaboration (Stack Overflow, 2025), against 35.6% for GitLab and 16.6% for Azure DevOps, same question and survey.
Git
Git wins on ecosystem. GUIs, editor integrations and hosting services exist for it in every shape, according to the Git project’s own About page.
Branching and merging are cheap enough to be daily actions, and nearly every operation only adds data, so committed work is hard to lose. It also has the biggest pool of tools, hosts and tutorials.
The downsides are real, though. The staging area and branch model add concepts to learn, and binary-heavy projects need extra tooling.
Experience does not remove the learning cost. An ACM study (2022) of Stack Overflow questions about Git commands found that most surveyed developers rated themselves only advanced beginner or competent, many after more than five years of use.
A primer on what Git actually does is worth reading before the setup steps below.
Subversion
The Apache Software Foundation has described Subversion’s mission since 2010 as “Enterprise-class centralized version control for the masses.”
Karl Fogel, its original founding developer, said in 2020 that Subversion shines wherever a centralized model fits the job (The Register).
It fits when a single shared server suits the workflow and branches stay few. It struggles when the work depends on frequent branching. Vincent Driessen, author of the git-flow model, recalled that in the CVS and Subversion world merging felt scary and happened rarely.
Mercurial and Perforce
Mercurial
Mercurial is a free, distributed source control tool where every clone holds the whole project history, per the official Mercurial site. Release 7.2 shipped on 29 January 2026 and 7.2.4 followed on 11 August 2026, so the project is still maintained.
Its weak spot is momentum. Mozilla moved the Firefox source of truth from Mercurial to Git on 30 April 2025, keeping Mercurial only to sync automated systems (DevClass).
Perforce P4 (formerly Helix Core)
Perforce is centralized, with a server and workspace to set up before the first file goes in. File locking stops people from overwriting files that others have open. Epic Games uses it for its own development and encourages Unreal Engine users to do the same, according to Perforce’s Unreal Engine tutorial.
Perforce renamed Helix Core to P4 in 2025, so you will see both names in documentation. It earns its setup cost when binary assets dominate the repository. For a code-only team, Git costs less.
Hosting Platforms
Hosting platforms add collaboration features on top of a Git repository.
| Platform | Underlying tool | What it adds |
|---|---|---|
| GitHub | Git | Pull requests, releases, Actions |
| GitLab | Git | Built-in issue tracking, code review, CI/CD |
| Bitbucket | Git | Atlassian’s hosted repositories |
| Azure DevOps | Git | Microsoft’s hosted repositories and work tracking |
The three survey percentages above add up to well over 100%, because respondents ticked every tool they use. Many developers work with more than one host.
GitHub leads by a wide margin, and an introduction to what GitHub is explains why most new projects start there.
How to Start Using Version Control
Git has to be on the machine first, and this guide on how to install Git covers each operating system. After that, setup runs from basic configuration through to a push to a remote.
- Set your name with
git config --global user.name "Your Name"and your email the same way, so every commit carries an author. - Run
git initinside the project folder. - Create a .gitignore for dependencies, build output and secrets.
- Run
git add ., thengit commit -m "Initial commit". - Start each new piece of work with
git checkout -b my-feature. - When it’s done, switch back with
git checkout main, then rungit merge my-feature. - Connect a remote with
git remote add origin <url>, then rungit push origin main.
The .gitignore step matters more than it looks. GitHub’s documentation recommends pulling dependencies through a package manager such as Bundler, npm or Maven instead of committing them.
A separate explainer on what a gitignore file does covers the pattern syntax.
If the wrong file lands in a commit, run git rm --cached FILE before pushing, then git commit --amend -CHEAD. A plain new commit does not help, because the file stays in the unpushed history (GitHub Docs).
Commit before you feel ready. Small commits are easier to review and easier to undo.
How Do Teams Collaborate With Version Control?
Each change gets its own branch, a review before it reaches the main line, and a merge once conflicts are resolved and the build passes. How long those branches live comes down to the branching strategy.
Branching Strategies
git-flow keeps main and develop alive permanently, with feature and release branches around them and hotfix branches for emergencies. Vincent Driessen published the git-flow branching model in January 2010.
Trunk-based development, by contrast, keeps one shared branch and avoids long-lived development branches.
The sources disagree on when git-flow still makes sense. Driessen’s own March 2020 note tells teams doing continuous delivery to pick a simpler workflow such as GitHub flow, and to keep git-flow for software that is explicitly versioned or supported in several versions at once.
The Trunk Based Development site goes further. It argues for trunk-based work instead of GitFlow, and says shared branches off the mainline are bad at any release cadence.
The split comes down to release shape. A product shipping 1.2 and 1.3 side by side needs release branches, while a web app that deploys from main does not.
Teams adopting trunk-based development lean on short-lived feature branches and feature flags, plus a build server that checks every commit. Without those, a single trunk breaks the build for everyone.
Pull Requests and Code Review
A pull request is a hosting-platform feature, not a Git command.
Mozilla shows the difference. Its 2023 migration plan put Firefox on GitHub but did not accept pull requests, keeping the existing Phabricator review flow (Mozilla Bugzilla).
On platforms that do support them, reviewers comment on the diff while an automated build runs on the branch, and nothing merges before approval.
The Trunk Based Development site accepts the pull-request workflow, as long as the branches stay short-lived.
Resolving Merge Conflicts
A conflict happens when two branches changed the same lines and Git cannot choose between them. To fix it, edit the file to the version you want, stage it, and commit.
Driessen’s own release process produces a conflict on schedule. Merging a finished release branch back into develop will probably collide, he notes, because the release branch changed the version number.
The Trunk Based Development site ties conflict volume to branch age. Committing to the trunk several times a day keeps branches from drifting far apart.
When Version Control Falls Short
Large binary files cause most of the trouble, along with formats that cannot be merged line by line. Because every clone carries the full history, heavy files slow down everyone.
Text is the happy case. The Git project reports that the full Linux history, 1.4 million commits, fits in 5.5 GB (git-scm.com, as of 2025).
Binaries are a different story. GitHub blocks files larger than 100 MiB in regular repositories, and its documentation says Git is not designed to handle large SQL files.
Binary files also cannot be opened as text or merged in a text-based tool, as Perforce’s Unreal Engine tutorial points out. Perforce answers with file locking.
Once a large file is pushed, getting it out of history takes git filter-repo, or an interactive rebase that only works when the commits sit on one branch with no merges since (GitHub Docs).
| Workaround | How it works | Catch |
|---|---|---|
| Git LFS | Replaces large files with text pointers, stores contents on a remote server | Per-file caps depend on the plan. Tracking a file type does not convert existing files, so run git lfs migrate |
| Perforce P4 (formerly Helix Core) | Centralized server with file locking | Server and workspace to set up and run |
| Plastic SCM | Built for large files and binaries, with workflows for artists | Now sold as Unity Version Control, aimed at game and real-time 3D teams |
Git LFS fixes file size, not merging. Its own getting-started example tracks .psd files, so layered design files are in scope.
Compiled output is a build artifact, and it does not belong in history at all. GitHub’s documentation points to releases for distributing large binaries.
A team of mostly artists with multi-gigabyte assets should skip plain Git. Start with Perforce P4 or Plastic SCM.
Version Control FAQ
Does SCM mean the same thing as version control?
It depends on the acronym. Source code management is another name for version control, and Mercurial’s own site calls itself a source control management tool.
Software configuration management is the wider discipline that version control belongs to, and a short guide to software configuration management shows where the two meet.
Is version control free?
Yes, the leading tools cost nothing. Git is released under the GNU General Public License version 2, and Mercurial describes itself as a free tool.
Money enters through hosting plans and large-file storage, where limits depend on the plan.
How often should I commit?
Commit each finished, self-contained change, and at least once a day on shared code. The Trunk Based Development site sets a daily commit to the trunk as the core rule of continuous integration.
Write each message for the next reader: what changed, and why.
Is semantic versioning the same as a Git tag?
No. Semantic versioning is a numbering scheme in the form MAJOR.MINOR.PATCH. The major number rises for incompatible API changes, the minor for backward compatible features, and the patch for bug fixes (Semantic Versioning 2.0.0).
A tag is the label that pins a commit. In a tag named v1.2.3, the semantic version is 1.2.3, and this note on semantic versioning covers the rules in full.
Switching Version Control Systems on a Live Project
Switching on a live project is manageable when the move runs in stages, and it pays off only when the current system blocks daily work, such as slow branching or unmergeable binary assets.
Mozilla needed more than a year between announcing the Firefox move to Git in late 2023 and completing it in April 2025 (DevClass).
Its published plan did the work in two stages, and that order is worth copying (Mozilla Bugzilla). First came the primary repository and developer tools, with one-way sync into the old system. After that, the surrounding infrastructure moved over in increments until the old system was fully retired.
The trade-off is a stretch of running two systems, with the old one fed by one-way sync from the new.
Teams settling on Git can pick up the daily commands in this walkthrough on how to use Git.
- How to Turn On Dark Mode in Notepad++ (Built-In, No Plugin) - October 3, 2026
- PostgreSQL Cheat Sheet - October 2, 2026
- How to Repair a Corrupt SQL Server Database Without Any Data Loss - October 2, 2026
