Why Version Control Exists: The Pendrive Problem

Before understanding why version control exists, we need to know what version control actually is.

Let’s understand version control with an example. Suppose you and a friend are building a project together, and each of you is working on different parts of it. As the project grows, changes are made frequently—new features are added, bugs are fixed, and existing code is modified. After a while, you start facing problems: you are unable to track what changes were made, who made them, and when they were made. Sometimes one person’s changes overwrite the other’s work, or a bug appears and you don’t know which change caused it.

This is where version control comes in. Version control is a system that helps you track and manage changes made to files over time. It keeps a complete history of every modification, allowing multiple people to work on the same project without interfering with each other’s work. With version control, you can compare different versions of a file, revert to a previous version if something goes wrong, and collaborate efficiently with others.

The Pendrive Analogy in Software Development

Before version control systems existed, software development was a lot like passing a single pendrive around a team and hoping nothing went wrong. Imagine a software team before Git, GitHub or any version control system existed .The pendrive is the only source of Truth for the project.

How work actually happened :

1. One pendrive, one project

   • The entire codebase lived inside a folder on a pendrive.

   • Whoever had the pendrive had the “latest” version.

2. Passing work physically

   • Developer A finishes some changes and hands over the pendrive.

   • Developer B plugs it in, edits the code, saves it, and passes it on.

   • Sometimes the pendrive was replaced by:

     • email attachments

     • shared network folders

     • Passing the pen drive

Different tool, same problem.

3. Copy–paste chaos

   • Each developer copied the project into their local machine.

   • Changes were made locally.

   • Later, files were copied back to the pendrive or shared folder.

This copy-and-paste loop is where everything broke.

Problems faced before Version Control System

1. No Change Tracking

• Imagine writing a big essay with friends, but everyone edits the same paper without keeping track of what changed.

• If something breaks, you don’t know who changed what or when it was changed.

• Result: Hard to fix mistakes and understand the history of the project.

2. Overwriting Each Other’s Work

• Two developers working on the same file might save it at the same time.

• The last person to save overwrites the other’s work, causing lost changes.

• It’s like two people painting the same canvas without coordination.

3. Difficulty Collaborating

Without VCS, sharing code meant sending files back and forth via email or shared drives.

• This gets confusing quickly, especially with multiple versions floating around.

• Team members waste time figuring out which file is the “latest” version.

4. Hard to Roll Back Changes

• If a change breaks the program, going back to an earlier working version is very hard.

• Teams might have to manually restore old copies, which is slow and error-prone.

5. No Branching or Experimenting

• Before VCS, trying new ideas meant editing the main code directly.

• Risky changes could break everything, and experimenting safely was almost impossible.