# Why Version Control Exists:  The Pendrive Problem

## Why Version Control Exists

Before starting, let me ask you a one simple question.  
Have you ever built a project during your college days and named it something like `final_project`, then `final_project_v2`, then `final_latest`, and sometimes even `final_latest_real`?  
If you have done this, don’t worry, you are not alone. Almost every beginner developer has followed this approach at some point.  
This habit exists because, naturally, we want to protect our work. We are afraid that if something breaks, we may lose everything. Since there is no proper system to track changes, we create multiple copies of the same project just to feel safe.

The real problem here is not poor naming.  
The real problem is the absence of a structured way to manage code changes.

As projects grow:

* Files change frequently
    
* Features get added and removed
    
* Bugs are introduced and fixed
    

Without a system to record what changed, when it changed, and why it changed, things quickly become confusing. This confusion is exactly the reason version control exists.

---

## The Pendrive Analogy in Software Development

Now let’s understand this problem using a real world style example.

Imagine two people working on the same project:

* Gurjeet Singh
    
* Steve Jobs
    

Gurjeet is building a feature and wants Steve’s feedback and improvements. Since there is no version control system, Gurjeet follows the most common old school approach.

1. He zips the entire project
    
2. Copies it to a pendrive
    
3. Hands the pendrive to Steve
    

Steve plugs the pendrive into his system, opens the project, adds some new features, and fixes a few bugs. After finishing his work, Steve again:

1. Zips the project
    
2. Copies it back to the pendrive
    
3. Gives it back to Gurjeet
    

At a very small scale, this looks manageable. But software development rarely stays small.

Now imagine:

* Both Gurjeet and Steve start working in parallel
    
* Both modify the same files
    
* Both add new logic independently
    

Suddenly, questions start appearing:

* Which version is the latest?
    
* Whose changes are correct?
    
* What if something breaks?
    

This is where the pendrive workflow begins to fail badly.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1767532947688/27ba57e3-c01b-48cb-8396-e273ee0a079a.png align="center")

---

## Problems Faced Before Version Control Systems

### 1\. No Change Tracking

Suppose Steve accidentally introduces a bug while working on the project. Later, Gurjeet notices that something is broken.

Now the problem is:

* There is no way to know which line was changed
    
* No idea who made the change
    
* No record of when the change happened
    

The entire project becomes a guessing game.

### 2\. Overwriting Code

If both developers edit the same file:

* Whoever copies the project last
    
* Overwrites the other person’s work completely
    

This leads to:

* Lost effort
    
* Wasted time
    
* Frustration between team members
    

### 3\. Folder and Zip File Chaos

### To avoid losing work, developers start creating backups:

* `project.zip`
    
* `project_backup.zip`
    
* `project_fixed.zip`
    
* `project_fixed_final.zip`
    

Instead of solving the problem, this creates new ones:

* Too many copies
    
* No clarity about the correct version
    
* Massive confusion
    

### 4\. No Collaboration History

Another major issue was the lack of history. Developers could not answer basic questions like:

* Why was this code added?
    
* Who approved this change?
    
* When did this bug first appear?
    

Everything depended on memory, emails, or chat messages, none of which are reliable for long term projects.

### 5\. No Central System

There was no single place where:

* Everyone could access the latest code
    
* Everyone could work together safely
    
* Everyone could see what others were doing
    

As teams grew larger, collaboration became slower and more dangerous.

---

## From the Pendrive Problem to Version Control

These exact problems were faced not only by beginners, but also by professional developers working on huge projects.

One such developer was Linus Torvalds.

While developing the Linux kernel, the codebase became extremely large and complex. Managing changes, tracking bugs, and coordinating contributions became very difficult.

To solve this problem, he created Git, a version control system.

Git was designed to:

* Track every change in code
    
* Maintain complete history
    
* Allow multiple developers to work together safely
    
* Go back to any previous version when needed
    

This is how version control was born, not as a luxury, but as a necessity.

---

## Why Version Control Became Mandatory

Version control systems solved everything the pendrive workflow failed at:

* No more `final_v2_latest` folders
    
* No accidental overwrites
    
* Full change history
    
* Easy collaboration
    
* Safe experimentation
    

This is why modern software development is impossible without version control.

---