Why Version Control Exists: The Pendrive Problem
1. Life before version control
Before Git, before GitHub, before fancy workflows, most of us started with one simple fear: what if I lose my code? You’re working on a project, you’ve spent hours writing logic, fixing bugs, breaking things, fixing them again, and finally it works. That’s when backup suddenly feels very important.
So you do the most obvious thing. You copy your project into a pendrive. Problem solved, at least it feels like it. Your code is safe now, and you can even share it with a friend if they want to add a feature or help with bug fixing. Everything seems fine until you want to improve the project further.
You already have a working version, let’s call it version1. Then one night you get a great idea and want to build version2. But you don’t want to touch the working code because every developer knows the first rule of programming: “if it works, don’t touch it”. So you create a new folder. Then another. Then another. Slowly your pendrive starts looking like this: version1, version2, version2_final, version2_final_final, final_app, final_app_working. At some point even you don’t know which folder is the real one.
Now you give the pendrive to your friend for bug fixing. They fix things and return it, but you have no idea what exactly they changed. Which file? Which line? Did they accidentally break something else? You just trust that it works and decide that the latest_final folder is now the source of truth. This is where things start getting messy.
2. Why the pendrive solution fails in real projects
The biggest issue shows up when you realise something important: only one person can have the pendrive at a time. If it’s with you, your friend can’t work. If it’s with your friend, you’re blocked. That means real collaboration, writing code at the same time, doesn’t exist at all in this setup.
Over time, this approach creates multiple problems:
Maintaining versions becomes confusing
Code gets overwritten accidentally
Changes are lost without anyone noticing
There’s no history of who changed what and why
Collaboration is slow and painful
As projects grow and more people get involved, this chaos grows too. The pendrive solution doesn’t scale, and it definitely doesn’t support how real software is built.
3. What version control actually solved
Version Control Systems were created to solve exactly these problems. A VCS is basically a system that keeps track of every change you make to your code. It knows what lines were added, what was removed, what changed, who did it, and when. Instead of creating new folders for every version, the system itself manages versions for you.
At first, you might think: why not just put this version-tracking software on the pendrive? But that still doesn’t solve the main issue. The pendrive can still be with only one person at a time. So the real breakthrough was moving the version control system to a server. Now you and your teammates can all connect to the same place, take a copy of the code, work independently, and then push your changes back.
This is where tools like Git come in, along with platforms like GitHub or GitLab. They provide a shared source of truth, allow multiple people to work at the same time, track every change safely, and help resolve conflicts when two people modify the same part of the code.
Final thought
In simple terms, version control is what replaced the pendrive. It turned messy folders into structured history, blocked collaboration into parallel work, and fear of breaking code into confidence to experiment. Once you understand this, Git stops feeling like a tool you have to learn and starts feeling like something that exists because developers needed it to survive.
If this made something click for you, great. That’s the goal. I’ll keep sharing things the way I wish someone had explained them to me when I started.