Why Version Control Exists: The Pendrive Problem

Source: Dev.to

Back then, bugs were manageable, but saving your work 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 the folders? They were filled with desperate names:

final
final_final
final_final_please_work
dont_touch_this_one

This wasn’t exaggeration or nostalgia; it was everyday life for developers, and it’s exactly why version control was born.

The problem was tangible

Before tools like Git existed, code didn’t live safely in the cloud. It traveled from person to person on USB drives, via email, inside shared folders, and 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?

Developers treated code like Word docs—open, edit, save, overwrite. Every overwrite erased part of the story.

Collaboration before version control

Imagine a small team sharing a single USB drive that holds the entire project.

1. Developer A updates some code, saves it, and passes the drive along.
2. Developer B edits something else and saves, overwriting A’s work.
3. Developer C is still using an older copy and adds changes there.

When the drive comes back around, no one knows:

• Which version is the latest?
• Which version actually works?
• Which change caused the bug?
• Why the intern pushed half‑finished code?

These weren’t sloppy habits; they were the only way teams could work at the time. The core questions remained unanswered:

• 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 grew, pendrives gave way to email attachments, FTP uploads, and shared company folders, but the issue stayed the same: code was shared, but changes were not tracked. Developers resorted to duplicating files and folders, leading to ever‑expanding directory names like:

project_final
project_final_v2
project_latest
project_latest_final
project_latest_final_please_work

Each name was a small act of hope. One careless save could erase days of progress, not because of bad habits but because the workflow simply didn’t support safe collaboration.

The real turning point: Linux and BitKeeper

Linux was a massive, globally‑used project with thousands of contributors changing the code daily. Starting in 2002, the Linux project relied on a proprietary tool called BitKeeper. When its free usage was discontinued in 2005, the community suddenly lost the system it depended on, and progress slowed.

With no open‑source alternative strong enough to replace BitKeeper, Linus Torvalds did what he tends to do when there’s no good option: he created one. The result was Git.

Birth of Git

Git was not built to look nice or be easy on day one. It was built to handle disorder at scale. Its 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 a single central server.

Git wasn’t designed to make developers comfortable; it was designed to make collaboration reliable.

How Git changed development

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 and became the core of modern software development.

Developers could now:

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

Errors stopped being scary; they turned into learning moments.

Impact

• 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.

Clarifying the difference between Git and GitHub

• Git – a software tool installed on your computer that tracks code changes. It works offline and requires no internet connection.
• GitHub (and similar services) – a website that stores Git repositories online, adds collaboration features such as issues, pull requests, and code reviews, and helps people work together.

Git existed first; GitHub helped it reach everyone. Git didn’t appear because developers were chasing the next shiny tool—it emerged because the old workflows were breaking under pressure.

Looking ahead

As Git matured, entire ecosystems formed around it—GitHub, GitLab, Bitbucket, SourceForge, AWS CodeCommit, Perforce—each solving collaboration in its own way. GitHub, in particular, evolved into 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.