Version Control Systems: How Developers Track Changes Without Losing Their Minds

Imagine working on a project without version control. You make a change on Monday and everything works. On Tuesday, you rewrite part of the application. By Wednesday, something is broken and you realise Monday’s version was better.

So you create copies:

website/
├── website-final/
├── website-final-2/
├── website-final-actually-working/
├── website-final-before-redesign/
└── website-final-use-this-one/

This works for about five minutes.

Now add six developers changing the same files, a production release that needs an urgent fix, and someone asking why a particular line of code changed three months ago. Keeping copies of folders is no longer enough.

This is the problem version control systems solve. A version control system, or VCS, tracks changes to files over time, preserving a revision history that developers can inspect, share, branch from, merge, and sometimes roll back when things go wrong.

Version Control Is a History of Changes

At its simplest, version control answers a few questions that become surprisingly difficult without it: what changed, when did it change, who changed it, and what did the project look like before the change?

Suppose a file originally contains:

const timeout = 30;

A developer changes it to:

const timeout = 60;

Without version control, the old value may simply be gone. With version control, both states can exist in the project’s history:

Revision 1
const timeout = 30;

        ↓ changed

Revision 2
const timeout = 60;

Repeat that process across thousands of files and years of development and you have something much more useful than a collection of backups. You have a record of how the software evolved.

Source Code Management Is Where Version Control Became Essential

Version control can track many kinds of text files, but it is particularly important for source code management.

Software changes constantly. Developers add features, remove old code, fix bugs, update configuration, change tests, and modify infrastructure files. Those changes are also interconnected: a five-line modification in one file might depend on another change elsewhere in the project.

A VCS keeps those revisions together and gives developers a shared history of the codebase. Instead of passing folders between computers or renaming files to preserve older versions, changes become part of a structured record.

That record normally lives inside something called a repository.

Repositories Hold the Project and Its History

A repository, often shortened to repo, contains a project under version control along with the information required to track its revisions.

Conceptually, it looks something like this:

Repository
│
├── Current project files
│   ├── src/
│   ├── tests/
│   └── README.md
│
└── Revision history
    ├── Commit A
    ├── Commit B
    ├── Commit C
    └── Commit D

The important distinction is that the repository is not merely the latest copy of the project. Its history lets developers inspect earlier states, compare revisions, understand how changes were introduced, and recover previous versions when necessary.

In systems such as Git, that history is built from commits.

Commits Turn Changes Into Meaningful Checkpoints

A commit records a set of changes in the repository’s history. Instead of treating every keystroke as a separate version, developers group related changes into meaningful checkpoints.

A simplified history might look like:

A ── B ── C ── D

A  Initial project
B  Add customer login
C  Fix password validation
D  Add password reset

Each commit represents a known state of the project and usually includes metadata such as the author, timestamp, and a message explaining the change.

This becomes useful months later when someone discovers that password validation behaves incorrectly. Rather than searching through random backup folders, the team can inspect the relevant commits and see how that part of the software changed.

Good revision history is therefore not just about preserving old code. It helps explain why the current code exists.

Branches Let Development Split Without Splitting the Project

Imagine the current production version is stable, but a developer needs several days to build a new checkout system. Changing the main version directly would mean unfinished work is mixed into everyone else’s development.

A branch creates another line of development:

A ── B ── C ─────────── F
          \
           D ── E
             feature

Both lines share the same history up to commit C. The feature branch then develops independently through D and E, while other work can continue elsewhere.

This is one of the most useful ideas in modern version control. Developers can experiment, build features, fix bugs, or prepare releases without creating completely separate copies of the project with no relationship between them.

The histories remain connected, which means they can later be brought back together.

Merging Brings Separate Histories Back Together

Once the feature is ready, its changes can be merged into another branch.

Conceptually:

A ── B ── C ─────── F ── G
          \             /
           D ── E ─────

Commit G represents the point where the lines of development have been combined.

Sometimes this happens automatically because the developers changed different parts of the project. If one developer changed the navigation while another changed database code, the VCS may be able to combine both without assistance.

The harder case occurs when two branches change the same part of the same file differently. That creates a merge conflict.

The version control system can identify the competing changes, but it cannot always know which one is logically correct. A developer has to examine both versions and decide what the final code should contain.

That is not version control failing. It is version control refusing to guess.

Collaboration Is Where Version Control Really Pays Off

A developer working alone still benefits from revision history and branches. With a team, version control becomes almost unavoidable.

Imagine three developers working simultaneously:

                 ┌── Feature: Search
                 │
Main ── A ── B ──┼── Feature: Payments
                 │
                 └── Fix: Login bug

Each developer can work on a different change while still sharing the same underlying project history. Their work can be reviewed, tested, and eventually integrated.

This is far safer than sending changed files through email or copying them into a shared folder, where one person’s version can easily overwrite another’s.

Version control does not remove the need for communication. It gives collaboration a technical structure.

Rollback Gives You Somewhere to Go When a Change Goes Wrong

One of the comforting things about version control is knowing that the current version is not the only version.

Suppose a deployment introduces a serious bug. Because earlier revisions still exist, the team can inspect what changed and potentially reverse the problematic change.

The basic idea looks like this:

A ── B ── C ── D
              ↑
          bad change

A ── B ── C ── D ── E
                  rollback

The exact method depends on the VCS and workflow. In Git, for example, a team might create a new commit that reverses an earlier one rather than deleting shared history.

This distinction matters because version control is not simply an undo button. History may already be shared with other developers, used in builds, or deployed to production. Reversing a change safely can be more important than pretending it never happened.

Centralized Version Control Uses a Central Source of Truth

Version control systems broadly fall into centralized and distributed models.

A centralized VCS uses one central repository that developers connect to:

Developer A ──┐
              │
Developer B ──┼── Central Repository
              │
Developer C ──┘

Developers typically check out working copies, make changes, and commit those changes back to the central server.

SVN, or Subversion, is a well-known centralized version control system.

This model is conceptually straightforward because there is an obvious central source of truth. It also means that access to the central repository plays a major role in normal development, and the server itself becomes an important part of the workflow.

Distributed Version Control Gives Developers Full Repositories

A distributed version control system works differently. Developers receive a local repository containing the project’s history rather than merely a working copy dependent on a central server.

The structure looks more like:

             Shared Remote
             Repository
             /    |    \
            /     |     \
           ↓      ↓      ↓
       Dev A    Dev B    Dev C
       Repo     Repo     Repo

Each developer can create commits, inspect history, create branches, and perform many other operations locally.

Changes can then be exchanged between repositories. In practice, teams usually still use a shared remote repository as their main collaboration point, but the underlying model remains distributed.

Git and Mercurial are both distributed version control systems.

Git Became the Dominant Version Control System

Git was created in 2005 for development of the Linux kernel and has since become the dominant version control system across much of software development.

Git is distributed, which means developers normally work with complete local repositories. It also makes branching relatively lightweight, encouraging workflows where developers create branches for features, bug fixes, experiments, and releases.

A typical Git workflow might look like:

Clone repository
      ↓
Create branch
      ↓
Change files
      ↓
Stage changes
      ↓
Commit
      ↓
Push
      ↓
Review
      ↓
Merge

Git itself handles the version control. The services developers commonly associate with Git provide another layer around it.

GitHub, GitLab, and Bitbucket Are Not Git

This distinction causes a lot of confusion when people first encounter version control.

Git is the version control system. GitHub, GitLab, and Bitbucket are platforms that host Git repositories and provide tools around them.

A simplified view is:

                    Git
          Version Control System
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
     GitHub        GitLab      Bitbucket
   Git hosting   Git hosting   Git hosting
   + reviews     + CI/CD       + teamwork

These platforms make distributed collaboration easier by providing a shared location for repositories. They also add features such as code review, pull or merge requests, issue tracking, permissions, automated builds, and CI/CD pipelines.

You can use Git without GitHub, and GitHub would not replace Git’s local version-control functionality. They solve related but different problems.

SVN Takes a Centralized Approach

Subversion, usually called SVN, approaches version control differently from Git.

Its traditional model is centralized:

Working Copy
     ↕
Central SVN Repository
     ↕
Working Copy

The central repository holds the authoritative history, while developers work with checked-out copies.

SVN is older than Git and is still used in existing systems and organizations. Its centralized model can also be useful in environments where teams specifically want tighter central control over repository operations.

The popularity of Git means new developers are more likely to encounter distributed version control today, but understanding SVN helps explain that Git’s model is not the only way version control can work.

Mercurial Shows That Distributed Version Control Isn’t Just Git

Mercurial is another distributed version control system. Like Git, it allows developers to maintain local repository history and exchange changes with other repositories.

The important point is not memorizing every VCS that has existed. It is recognizing the larger models:

Centralized VCS
Developer → Central Repository ← Developer

Distributed VCS
Repository ↔ Repository ↔ Repository

Git became enormously popular, but distributed version control is a broader idea rather than a Git-specific invention.

Version Control Does More Than Protect Against Mistakes

It is easy to introduce version control as a way to recover an old file, but that undersells what it becomes in a real software project.

A repository records how the system evolved. Commits divide that evolution into meaningful changes. Branches allow work to proceed independently, while merging brings those changes back together. Shared repositories allow many developers to collaborate without constantly overwriting one another’s work.

That history also becomes useful outside development. Code reviews can discuss specific changes. Automated systems can build and test particular commits. Releases can be associated with known revisions, and production incidents can be traced back to the changes that introduced them.

Version control gradually becomes the timeline around which much of software development is organized.

The Real Value Is Knowing How You Got Here

Without version control, a project mostly tells you what exists now.

With version control, it can tell you how it got there.

Yesterday          Today             Tomorrow
   │                  │                  │
   ▼                  ▼                  ▼
Commit A ── Commit B ── Commit C ── Commit D
                \                    /
                 ── Feature Branch ──

That history matters because software is rarely finished. Requirements change, bugs appear, developers join and leave, experiments fail, and code that looked sensible six months ago eventually needs replacing.

Version control systems give all of those changes a structure. Centralized systems such as SVN keep that history around a central repository, while distributed systems such as Git and Mercurial give developers repositories of their own. Platforms such as GitHub, GitLab, and Bitbucket then build collaboration workflows around Git repositories.

The individual tools differ, but the underlying problem has barely changed: software changes constantly, and those changes need to remain understandable.

A good version control history does more than preserve old code. It leaves a trail showing what changed, who changed it, how different pieces of work came together, and where the team can go if the latest version turns out not to be the right one.