Why Version Control Exists: The Pendrive Problem
Understanding Version Control: The Issue with Using Pendrive

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.
He zips the entire project
Copies it to a pendrive
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:
Zips the project
Copies it back to the pendrive
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.
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.zipproject_backup.zipproject_fixed.zipproject_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_latestfoldersNo accidental overwrites
Full change history
Easy collaboration
Safe experimentation
This is why modern software development is impossible without version control.




