Why Version Control Exists: The Pendrive Problem

Aditya Giri — Sat, 17 Jan 2026 13:11:50 +0000

INTRODUCTION:

Back then, bugs were manageable. Saving your work? That took courage.

Pressing Ctrl + S felt like defusing a bomb.

Was this the correct file?

Had someone else already made edits?

Would this action erase hours of someone else’s work?

There was no undo button for teams.

No rewind.

No safety net.

Just hope.

And folders with desperate names:

final
final_final
final_final_please_work
dont_touch_this_one

This isn’t exaggeration.

This isn’t nostalgia.

This was everyday life for developers - and it’s exactly why version control was born.

🌍 Life Before Git

Before tools like Git existed, software development was… very tangible.

Code didn’t live safely in the cloud.

It traveled from person to person.

On USB drives.

Via emails.

Inside shared folders.

Through FTP servers.

Code moved like physical documents, not as part of a tracked history.

At its heart, version control solves one fundamental problem:

How do multiple people work on the same code without wiping each other out?

Today, that seems obvious. Back then, it was anything but.

Developers treated code like Word docs - open, edit, save, overwrite.

And every overwrite erased part of the story.

💾 The Pendrive Story

Collaboration before version control

Picture a small team working on a single project.

Now imagine they share just one USB drive.

Yes - only one.

That single drive holds the entire project.

Developer A updates some code, saves it, passes the drive along.
Developer B edits something else and saves… overwriting A’s work.
Developer C is still using an older copy and adds changes there.
The drive comes back around again.

And no one knows:

Which version is the latest
Which version actually works
Which change caused the bug
Or why the intern pushed half-finished code

This wasn’t sloppy teamwork.

It was the only way they knew.

❌ Challenges Teams Dealt With

Development teams were stuck guessing answers to basic questions:

Who made this change?
Which file should we trust?
When did this bug first appear?
Why does it run fine on one computer but fail everywhere else?
Did someone test this directly on production?

As projects became larger, pendrives slowly gave way to:

Email attachments
FTP uploads
Shared company folders

But the core issue stayed the same.

Code was shared. Changes were not tracked.

So developers relied on the only solution they had - duplicating files and folders.

📁 When Folders Took Over

Project directories began to grow out of control:

project_final
project_final_v2
project_latest
project_latest_final
project_latest_final_please_work

Each folder name was a small act of hope.

Teamwork became risky.

One careless save could erase days of progress.

And this wasn’t due to bad habits.

At the time, this was simply how things were done.

Until developers reached their limit.

⚠️ Why Git Came Into Existence

The real turning point was Linux.

Linux wasn’t a small side project.

It was huge.

Used worldwide.

Worked on by thousands of developers.

Changing every single day.

Starting in 2002, the Linux project relied on a proprietary tool called BitKeeper.

For a while, it did the job - until its free usage was discontinued in 2005.

Almost instantly, the Linux community lost the system it depended on.

Progress slowed.

Teamwork became difficult.

And there was no open-source tool strong enough to replace it.

So Linus Torvalds did what he tends to do when there’s no good option available.

He created one.

🛠️ How Git Was Born (2005)

Git was not built to look nice.

It was not built to be easy on day one.

It was built to handle disorder at scale.

The goals were simple and strict:

Never lose work - every change must be saved
Support very large projects
Be extremely fast
Work well for distributed teams, without relying on one central server

Git wasn’t designed to make developers comfortable.

It was designed to make collaboration reliable.

✅ What Git Fixed

Problems that developers once accepted as normal suddenly had solutions:

Deleted or overwritten code could be recovered
Conflicting changes could be resolved cleanly
Teamwork became structured and predictable
Every change gained a permanent record

Version control stopped being a temporary fix.

It became the core of modern software development.

🌱 Life After Git

Git didn’t just introduce a new tool.

It changed how developers think and work.

Now, developers can:

Try new ideas without worrying
Work on features in separate branches
Undo mistakes in seconds
Work together with confidence

Errors stopped being scary.

They turned into learning moments.

The impact was huge:

=> Open-source projects grew rapidly

=> Personal projects felt less risky

=> Teams became more open to change

=> Development became less stressful

Git didn’t remove mistakes.

It removed the fear of making them.

🔍 Git vs GitHub

One last confusion worth clearing:

Git

A software tool
Installed on your computer
Keeps track of code changes
Can be used without internet

GitHub

A website and service
Stores Git projects online
Helps people work together
Adds features like issues, pull requests, and reviews

Git existed first.

GitHub helped it reach everyone.

🧠 Final Takeaway

Git didn’t appear because developers were chasing the next shiny tool.

It emerged because the old workflows were simply breaking under pressure.

As Git matured, entire ecosystems formed around it - GitHub, GitLab, Bitbucket, SourceForge, AWS CodeCommit, Perforce - each solving collaboration in its own way.

Yet GitHub evolved into something more than a tool.

It became a shared stage, where developers collaborate publicly and ideas grow in the open.

In the next article, we’ll move from why Git exists to how it works, exploring Git fundamentals and essential commands step by step.

DEV Community: Aditya Giri