Why Version Control Exists: The Pendrive Problem

Before Version Control: How Developers Used to Work

So when I started learning web dev, Git was just there. Everyone uses it. It's standard. I learned git add, git commit, git push from day one. Then I explored Git internals, opened up the .git folder, and understood how everything works.

I just finished a major project of mine recently. And that day, this thought came to my mind: how did developers even collaborate before version control existed? Like, Git was created in 2005, but people were writing software way before that, right? How did teams work together? How did they manage code?

I got really curious about this, so I started googling and looking into it. And honestly? What I found was absolute clutter.

The Pendrive Era

Back before version control was a thing, developers had to manage their code manually. Like really manually. No automated systems, no cloud, nothing. Just people, computers, and USB drives.

How It Actually Worked

Okay so let’s suppose there are three developers working on the same project.

Developer A writes some code on his laptop. He saves everything to a pendrive. Then he physically walks over to Developer B's desk and hands him the pendrive. Developer B plugs it in, copies the code to his laptop, makes his changes, saves everything back to the pendrive. Then he walks to Developer C and hands it over.

This was the actual workflow. Physical handoff of storage devices. Sounds simple, right? Well, here's where things got messy.

The Problem

Let's say Developer A spent hours fixing this really complicated bug. He's exhausted but relieved because he finally got it working. He saves everything to the pendrive and gives it to Developer B.

Now here's what happens next. Developer B has his laptop open. He has some old version of the code sitting there from like two days ago. He doesn't realize it's outdated. He makes his changes on that old code. Then he copies it back to the pendrive, overwriting everything. Developer A's hours of work? Gone. Just like that. Completely overwritten.

And the worst part? There's no way to get it back. No undo button. No history. No backup. It's just gone forever. I literally can't imagine how frustrating this was. You work an entire day on something and then poof, it disappears because someone accidentally used the wrong version.

The File Naming Nightmare

So after losing code like this multiple times, developers started getting smart. Or at least they thought they were getting smart. They began making backup copies of everything.

A typical project folder would look like this:

📁 MyProject/
📄 login.js
📄 login_backup.js
📄 login_working.js
📄 login_final.js
📄 login_final_v2.js
📄 login_final_ACTUAL.js
📄 login_latest.js
📄 login_tested.js
📄 login_USE_THIS_ONE.js
📄 login_march15.js
📄 login_REAL_final.js

This was literally the system people used to keep track of versions.

The Problem

Now imagine coming back to this folder after a week. Which file is actually the latest one?

Is it login_ACTUAL_final.js? Or wait, did someone make changes after that? So is it login_USE_THIS_ONE.js? But then why is there a file called login_latest.js? Is that newer? What about login_march15.js? When was that even created? Nobody knows. Complete mess. And when you have three or four developers all doing this on their own laptops? The clutter multiplies by 10.

Email Based "Version Control"

Then email became common in workplaces and developers thought "okay great, we'll just email code to each other!"

Spoiler: This made things worse. A typical day looked like this

9:00 AM

Developer A sends an email to the team:

"Hey everyone, I fixed the password validation bug. Attached is the latest version of the login module. Please use this going forward." 

10:30 AM

Developer B sends another email:

"Hi team, I just added the logout feature. Here's the updated code. Use this one instead."

11:00 AM

Developer A sends another email:

"Wait I just fixed the database connection issue too. This is the actual latest version now. Ignore my previous email." 

2:00 PM

Developer C replies confused:

"Um guys, which version should I be using? I have three different files in my inbox all called 'latest'." 

4:00 PM

The manager sends a frantic email:

"URGENT: We have five different 'latest versions' floating around. Meeting in 10 minutes."

This looked absolutely horrible when I read about it. Even today when people don't use Git properly, emails become a mess. But imagine this being the ONLY way to share code.

Real Problems Developers Faced

Here are the actual problems that made this system completely broken.

Problem 1: Lost Work Forever

This one was the absolute worst. A developer spends an entire day writing some complex feature. Saves everything to a pendrive. Goes home. Next morning the pendrive is corrupted. Won't even open. All that work? Gone forever. No backup. No history. No recovery possible. The developer literally has to start over from scratch.

I can't even imagine this. These days if my laptop crashes, my code is safe on GitHub. Back then? If your pendrive failed, you were literally done.

Problem 2: Overwriting Work Accidentally

This happened constantly.

Developer A fixes a critical bug in database.js on Monday morning. Developer B doesn't know about this. On Monday afternoon, Developer B finds an old version of database.js in his backup folder. He thinks his version is newer and copies it to the shared folder. Boom, Developer A's bug fix is gone. Overwritten. The bug is back in the code. Nobody realizes until the application crashes.

And there's no way to know what happened. No commit history. No way to see who changed what. Nothing.

Problem 3: No Change History

Someone asks "Hey this login function was working fine last month. Now it's broken. What changed?"

The answer back then? "Uh, no idea. Nobody kept track of changes. Want to spend the next 4 hours comparing old files line by line?"There was literally no way to see what changed in the code, when it changed, who changed it, or why they changed it.

Every debugging session became a mystery with zero clues.

Problem 4: One Person Per File

Here's something that really shocked me when I learned about it. Only ONE person could work on a file at a time.

Teams would literally have a physical whiteboard in their office that looked like this:

📋 FILE CHECKOUT BOARD

login.js → Akshay (Mon 9 AM) ✓ IN USE 

database.js → Naman (Tue 2 PM) ✓ IN USE 

utils.js → AVAILABLE

app.js → Gurpreet (Wed 10 AM) ✓ IN USE

Before editing any file, you had to walk to this board and write your name next to it. This told other developers "hey I'm working on this, don't touch it." If you wanted to edit login.js but John was already working on it? You literally had to wait. Walk to his desk. Ask him "hey are you done with that file?"

Can you imagine? These days I work on the same repository with multiple people simultaneously. We all commit and push whenever we want. Git handles everything.

Back then? Queue up and wait your turn like you're at a government office.

Problem 5: Integration Day Horror

This one sounds like actual nightmare fuel. Teams would work like this: Monday to Thursday: Everyone codes on their own laptops. Completely separately. Nobody knows what anyone else is doing.

Friday afternoon: Integration Day. Everyone brings their code. Usually on pendrives or through email. Then one person (usually the most senior developer, poor guy) tries to manually combine everyone's changes.

And the nightmare begins.

Everyone edited the same files in different ways. Conflicts everywhere. Code won't compile. Things break. They spend the next 6 hours trying to figure out what went wrong. Often working late into the night. Sometimes even over the weekend. Sometimes they just give up and redo parts from scratch. Modern Git merges? Automatic conflict detection? Pull requests? We are so spoiled.

Problem 6: No Way to Roll Back

You deploy a new feature on Friday evening. Monday morning, everything is broken. The feature introduced critical bugs. Production is down. Customers are calling.

What you want: "Just go back to Thursday's working version." What actually happens: "Does anyone have Thursday's code saved somewhere? Anyone? No? Okay let's try to manually remember everything we changed and undo it..." No git revert. No git reset. No safety net. If you broke something, you manually fixed it or prayed someone somewhere had an old backup.

When It Became Impossible

This chaotic system kind of worked when projects were small and teams were tiny. But as software got more complex, everything collapsed. That's when people realized, we desperately need something better. This manual way of managing code just doesn't scale.

Version Control Systems Arrive

The software industry finally learned from all this mess and started building actual solutions.

1972 - SCCS (Source Code Control System) was created. The first ever version control system. Very basic but better than pendrives.

1982 - RCS (Revision Control System) came out. Improved file tracking. Still pretty limited.

1990 - CVS (Concurrent Versions System) was released. This was huge. Multiple developers could finally work at the same time! Files weren't locked anymore. Automatic merging became possible.

2000 - SVN (Subversion) improved on CVS. Better handling of files. Centralized system with one main server.

2005 - Git was created by Linus Torvalds for Linux development. Distributed system. Super fast. Powerful branching and merging. Completely revolutionized development.

And now Git is everywhere. GitHub, GitLab, Bitbucket. Every single developer uses it.

How Git Solved Everything

Before:

After:

Remember all those problems I described? Here's how Git solved every single one.

Lost Work Forever? Back then, if your pendrive got corrupted or you accidentally deleted something, it was gone forever. No undo button. No recovery. Now with Git and GitHub, your entire code history is safely backed up in the cloud. Your laptop could literally explode and your work would still be safe on GitHub.

Accidentally Overwriting Someone's Work? This happened constantly with pendrives. Someone would copy an old version back to the shared drive and boom; hours of work disappeared. With Git, this is literally impossible. Every change is tracked. Git won't let you push if it would overwrite someone else's work. You have to pull their changes first and merge them.

No Way to See What Changed? Before version control, if something broke, you had no idea what changed or who changed it. You'd spend hours comparing files line by line trying to find the bug. Now? git log shows you every single change ever made. You can see exactly who changed what line of code, when they did it, and why (from their commit message). Debugging became so much easier.

Only One Person Could Work on a File? Companies literally had physical whiteboards where you'd write your name next to a file to "check it out." If someone else wanted to edit that file, they had to wait. Sometimes for hours. Can you imagine? Now with Git, everyone can work on the same file simultaneously. Git automatically merges changes when possible, and if there's a conflict, it clearly shows you where and helps you resolve it.

Weekly Integration Nightmares? Teams would code separately all week, then spend 6+ hours every Friday manually merging everything. Conflicts everywhere. Code not compiling. Everyone working late. Now git merge handles it automatically. And if you're working on a feature branch, you can merge multiple times a day with zero drama. Integration went from a painful weekly event to a smooth continuous process.

No Way to Roll Back Bugs? If a bug made it to production before Git, rolling back was a manual nightmare. You'd try to remember what you changed and manually undo it. Sometimes you'd make it worse. Now? git revert or git reset and you're instantly back to any previous working state. Made a mistake? Just go back in time. It's that simple.

When you really think about it, it's crazy how much Git changed everything. It didn't just make collaboration easier, it made modern software development actually possible. All those decades of frustration, solved by one system.

Wrapping Up

So that's why version control exists. It's not just some trendy tool developers use. It literally solved decades of actual nightmares, lost work, overwritten code, integration disasters, and manual everything.

Sometimes I run git commit, I think about those developers who had to physically walk around with pendrives and write their names on whiteboards just to edit a file. We're insanely lucky to have Git.

If you're new to Git, don't stress about learning everything at once I mean take proper time. Also in my next blog, I'll cover the essential Git commands you need to know the once you'll use every single day. After that, I'll show you Git's internals, what actually happens inside that mysterious .git folder when you run those commands.

But for now, just appreciate that Git exists. Because the alternative? Pendrives, emails, andlogin_final_v2_ACTUAL_USE_THIS_ONE.js files. And nobody wants to go back to that nightmare.