Why Version Control Exists: The Pendrive Problem

So before Git and GitHub, what existed?
Dinosaurs? Yes, technically.
But after them, software developers entered a much darker age: the Plastic Era.

This was the time when code was shared using a sacred object known as the Pen Drive.

The Plastic Era of Code Sharing

If you’re wondering how code was shared using a pendrive, it’s exactly like managing a group PPT submission in college. You’ve seen these filenames:

• Final_PPT

• Final_submission_ppt

• final_submission_latest.ppt

• final_REAL_submission_v2.ppt

Most of the time, the only actual change was the theme color from blue to orange. Yet somehow, we had ten “versions” of the same file.

That was version control. Sort of. If you squint hard enough.

How the Pendrive Workflow Actually Worked

The process was dead simple:

1. Write code on your machine

2. Copy it to a pendrive

3. Hand the pendrive to another developer

4. They make changes

5. Copy it back

That pendrive became the single source of truth. Whoever had it owned reality.

This system looked cute and cooperative until someone said:

“Why did you make changes in this file when I was working on it?”

When Things Started Breaking

Imagine this scenario.

• dev_1 is building Feature A and creates lib/utils.ts for some helper functions.

• dev_3 is building Feature C, completely unrelated.

• Irony hits. Both need a utility function.

• Both create lib/utils.ts.

• Both even name the function the same.

• Output interfaces differ slightly.

Now merge those changes using a pendrive.

Congratulations, you’ve unlocked confusion.

Now multiply this problem across 60% of your codebase.

At this point:

• You don’t know who wrote the function

• You don’t know where it’s used

• You don’t know which version is correct

• You don’t know who to blame

Peak productivity.

Why the Pendrive Was the Problem

The pendrive wasn’t evil. It was just extremely bad at its job.

Some core issues:

• Only one person could work at a time to avoid conflicts

• Development speed was painfully slow

• No credibility. Who wrote what? Who fixed what?

• No history. Once something broke, it broke permanently

• No version control, just vibes and backups

You might think, “Why not use final_v1, final_v2, etc.?”

Sure. But even a tiny change, like updating a theme color, required duplicating the entire project. Storage got wasted fast. Mental sanity even faster.

The First Obvious Fix: The Cloud

Next logical step: remove the physical object.

Instead of a pendrive:

• Store code on the cloud

• Developers download, modify, and upload again

This solved physical dependency, but not much else.

Problems still remained:

• Logs were weak or manual

• Versioning still meant duplicates

• Storage costs increased

• Collaboration conflicts still happened

So close. Still bad.

Enter Version Control Systems

Eventually, developers got tired of this nonsense and did what developers do best: build a system to fix it.

Version Control Systems (VCS) solved multiple problems at once:

• Track who changed what

• Maintain complete history

• Optimize storage

• Enable real collaboration

• Allow safe merging, even on the same file

Version control stopped being optional. It became mandatory for any serious software.

Merge conflicts still hurt, but now they’re like a bad breakfast. Annoying, survivable, and not career-ending.

How Version Control Actually Solves the Issues

1. A Clear Mechanism
   Files are organized and tracked systematically.

2. Collaboration and Credibility
   Developers work on branches. Every change has an owner.

3. Space Optimization
   Only changed files are stored as new versions. Everything else is referenced.

No unnecessary duplication. No guessing games.

Types of Version Control Systems

• Local Version Control Systems (LVCS)
  Changes are stored locally as patches on one machine.

• Centralized Version Control Systems (CVCS)
  One central server holds the repository. Developers check out and commit changes.

• Distributed Version Control Systems (DVCS)
  Every developer clones the full repository with complete history. This is where Git lives.

Conclusion

Version control exists because copying files is not collaboration.

The pendrive era taught developers a painful lesson:
code needs memory, ownership, and structure.