Why Version Control Exists: The Pendrive Problem

Source: Dev.to

Introduction

Before Git became the backbone of modern software development, collaboration was fragile, manual, and surprisingly primitive.

Developers didn’t clone repositories or push commits. They passed pendrives.

Each pendrive contained a slightly different version of the same project. Nobody knew which one was correct, who changed what, or when a bug was introduced. One wrong overwrite could erase days of work.

This was not a rare inconvenience—it was a structural problem that made teamwork slow, risky, and unscalable.

That everyday pain point eventually forced developers to rethink how code should be shared, tracked, and trusted. Out of this chaos emerged a system that changed software development forever: Git.

In this article we will explore why Git was created, what problems existed before it, and how developers managed code before modern version‑control systems.

Before understanding why version control exists, let’s first clarify what version control actually is.

According to the Internet, Version control (also known as revision control, source control, or source‑code management) is the software‑engineering practice of tracking and managing changes to computer files—primarily source code.

That definition sounds technical, but the idea is simple.

Version control is a way to track changes in your code so you can see what changed, when it changed, and roll back to an earlier version if something breaks.

In other words, it gives your code a memory.

So the real question is: why was this needed in the first place?

The Pendrive Era

Let’s go back in time and imagine a world without Git.

You are a developer working on a project. One day you need help implementing a new feature, so you ask your friend Abdul to collaborate. He agrees and asks for the code.

To share it, you zip the project, copy it to a pendrive, and ship it to him. Abdul implements the feature, zips the updated project, and sends the pendrive back.

When you unzip the project, the first issue becomes clear: there is a lot of code, and you have no idea which part was written by whom. Since the feature works, you ignore the issue and move on.

A few days later you discover a bug in the feature Abdul wrote. You send the entire project back to him on the pendrive. He fixes the bug and returns it.

Now you know the code has changed—but you don’t know what changed or where. To understand the modifications you have to sit together and compare changes line‑by‑line, which is time‑consuming.

Another major issue emerges: while Abdul is working on the code, you cannot safely work on it yourself. If you do, you both end up with different versions of the same project—leading to conflicts and wasted effort.

These problems become even more painful as the codebase grows and more developers join. Imagine a third developer, Chitra, joining the effort. There is no way for all three of you to collaborate in real time while ensuring the code does not get out of sync.

A further issue is the inability to see what was updated when, who updated it, and the whole timeline of changes. As the timeline progresses, previous versions get lost, leaving you with a completely bugged‑out codebase and no way to revert to a known good state.

Simple example:

• Abdul works on a bug in a feature, modifies the code, and hands the pendrive to Chitra because her feature is also causing issues.
• Chitra makes additional modifications.
• When the pendrive finally returns to you, you are completely clueless about what has happened to the project.

Problems Faced Before Version‑Control Systems

• Overwritten code – The last person to save often erased someone else’s work.
• Lost changes – Hours of work could vanish due to outdated copies.
• No collaboration history – There was no reliable way to trace who changed what or why.
• Wasted time – Only one developer could safely work at a time.
• Constant confusion – Teams struggled to identify which version of the code was the correct one.

How Version Control Fixed the Pendrive Problems

Now let’s think about solving these problems.

The first challenge is to track who made what changes. To solve this, imagine creating a software system that:

1. Tracks code changes.
2. Stores the author of each change.
3. Shows differences between old and new code.
4. Maintains a complete version history.

This solution would address the first two problems: tracking changes and identifying contributors.

A simple idea emerges: build a tool that records the author, timestamp, and a contextual note each time a change is committed. Let’s call this CCT (Code Changes Tracker). Deploy CCT on the pendrive, and… problem solved?

Partially. While CCT would give you a log of who changed what and when, it would still rely on manual distribution of the pendrive, leaving the core issues of synchronization, conflict resolution, and centralized history unsolved.

The next step was to move the tracking system to a shared, network‑accessible repository, add branching and merging capabilities, and automate the distribution of changes. That evolution gave birth to modern version‑control systems—and ultimately to Git.

# From Pendrives to Distributed Version Control

Developers used to **copy code onto a pendrive**, hand it to a teammate, and hope the changes didn’t get lost.  
If something went wrong, the only way to recover was to **re‑create the history manually**.

Now we can **see the history and revert**, which was not possible before.

![Code Change Tracker](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pext825jw7ml1ifgqdky.png)

The Real‑Time Collaboration Problem

Even with proper version tracking, each developer still had their own local copy of the project.
Everyone had history — but not necessarily the same history.

The core question shifted from:

• “Who changed this?”
• “What changed?”

to:

• “Which version should everyone be working on?”

This is no longer just a versioning problem — it’s a collaboration and coordination problem, because only one developer could work at a time while the source code still existed in a single physical location.

The First Attempt: A Central Server

Developers set up a cloud server to store the code, calling it CCTS (Code Changes Tracker Server), and deployed the CCT there.

At this point it seemed the pendrive era was over:

• A system that tracks changes
• A server that stores the code
• Multiple developers working together

However, early centralised version‑control systems still had a critical weakness: everything depended on the central server.

• If the server went down, development stopped.
• If the server lost data, the project history was gone.
• Developers could not work freely without constant access to that single machine.

In other words, collaboration was possible—but fragile.

The Architectural Shift That Made Git Different

Git flipped the model entirely. Instead of a central server holding the complete history, every developer receives a full copy of the codebase along with its entire history.

This allowed developers to:

• Work offline
• Experiment safely
• Recover from failures
• Collaborate without a single point of failure

The server became a shared coordination point, not a dependency.

Key Insight

• CCT (Code Changes Tracker) represents Git — the distributed version‑control system.
• CCTS (Code Changes Tracker Server) represents platforms like GitHub — which make collaboration easier, but are not required for Git to work.

The Birth of Git

Git was created by Linus Torvalds to manage his main project: Linux. As Linux grew, tracking changes became extremely difficult. The developers tried BitKeeper, a proprietary VCS that was fast, efficient, and suited for a large, distributed team. BitKeeper offered free licenses to the Linux community, so they adopted it.

However, a community member attempted to reverse‑engineer BitKeeper, which angered its creators. Trust was shattered, and free access to BitKeeper was revoked.

Faced with the loss of a critical tool, Linus vowed never to rely on proprietary software again. He set out to build his own distributed version‑control system—free, open‑source, and completely independent.

And so, Git was born.

Alternatives to Git (VCS)

• SCCS (Source Code Control System)
• RCS (Revision Control System)
• CVS (Concurrent Versions System)
• Mercurial
• Apache Subversion
• Fossil
• AWS CodeCommit

Alternatives to GitHub (Hosting Platforms)

• Bitbucket
• GitLab
• Gitea
• Codeberg

Conclusion

Version control did not emerge from theory or best practices—it emerged from pain.

The pendrive era showed what happens when there is no reliable way to track changes, no shared history, and no scalable collaboration model. Code was overwritten, bugs were hard to trace, and teamwork simply did not scale.

• Git solved the tracking problem by recording every change as history.
• Platforms like GitHub, GitLab, and Bitbucket solved the coordination problem by giving teams a shared place to collaborate.

That is why version control is no longer optional—it is foundational to modern software development.

If you have ever pushed a commit, resolved a merge conflict, or rolled back a mistake, you are benefiting from solutions that were born out of something as simple—and painful—as passing pendrives.

Understanding this history doesn’t just make you a better Git user. It makes you a better engineer.

Follow for more beginner‑friendly breakdowns of core software engineering concepts.