# Why Version Control Exists: The Pendrive Problem

**The Pendrive Story Every Developer Has Lived:** Before Git, before GitHub, before “commit” and “push” became everyday words — developers still wrote code.  
But the way they managed it was… painful.

## Life Before Version Control Systems

Imagine you’re a developer in a small team.

There’s **no Git**, no cloud repositories, no collaboration tools.

You still need to:

* Write code
    
* Share it with teammates
    
* Make changes without breaking others’ work
    
* Recover old versions if something goes wrong
    

### The Pendrive Era

![](https://rukminim2.flixcart.com/image/300/300/jumzc7k0/pendrive/pendrive/d/y/w/sandisk-2gb-pendrive-original-imaffpym9hgkufdq.jpeg align="center")

The most common tool?

**A pendrive.**

Yes — a single pendrive that moved from:

* Developer A → Developer B → Team Lead → Tester
    

Each person would:

1. Copy the project folder
    
2. Make changes
    
3. Rename the folder
    
4. Pass it forward
    

Folders looked like this:

```plaintext
project
project_final
project_final_v2
project_final_v3
project_latest
project_latest_final
project_latest_final_FIXED
```

## Emails as Version Control

If pendrives weren’t used, then emails were.

* “Here is the latest [code.zip](http://code.zip)”
    
* “Ignore previous mail, use this one”
    
* “Sorry, wrong attachment, sending again”
    

Inbox version history:

```plaintext
code.zip
code_final.zip
code_final_really.zip
code_final_fixed.zip
```

No one knew:

* Which file was correct
    
* Who made which change
    
* What exactly changed  
      
    **Problems Faced Before Version Control Systems**
    
    Before tools like Git existed, developers still wrote software—but managing changes was a daily struggle.  
    There was no proper system to track code history, collaborate safely, or recover from mistakes.
    
* ## 1\. Accidental Code Overwriting
    
    The biggest issue was **overwriting someone else’s work**.
    
    Scenario:
    
    * Two developers work on the same project
        
    * Both make changes independently
        
    * One copies their version last
        
    
    💥 Result:  
    The other person’s work is **completely lost**.
    
    There was no merge, no warning, no conflict resolution.
    
* ## 2\. No Record of Changes (No History)
    
    When something broke, teams asked:
    
    * Who changed this?
        
    * When was this added?
        
    * Why was this removed?
        
    
    Most of the time, there was no answer.
    
    Files only showed the current state, not how they evolved.
    
    If a bug appeared, debugging meant guessing.
    
* ## 3\. Impossible or Unsafe Rollbacks
    
    If today’s code didn’t work:
    
    * You couldn’t easily go back to yesterday’s version
        
    * You depended on someone having an old backup
        
    
    Many teams relied on:
    
    * Folder copies
        
    * Email attachments
        
    * Old pendrive versions
        
    
    ## 4\. Folder Chaos (final, final\_v2, latest)
    
    Without version control, developers used **folder names as version history**:
    
    ```plaintext
    project
    project_final
    project_final_v2
    project_latest
    project_latest_final
    ```
    
    Problems:
    
    * No clear “correct” version
        
    * Easy to open the wrong folder
        
    * No idea what actually changed