Why Version Control Exists: The Pendrive Problem
Before tools like Git, developers shared code using pendrives, emails, and folders named final, final_v2, and latest_final. Code got overwritten, changes were lost, and there was no clear history of who changed what or why. Version control exists because that way of working doesn't scale—and it breaks down fast when more than one person touches the same codebase.
Why Version Control Exists (The Big Picture)
The basic problem
Software is never really "done." You fix bugs, add features, try experiments, and sometimes break things. More than one person often works on the same files. Without a system to track changes, you end up with:
Overwriting – Someone's work replaces yours (or vice versa).
Lost changes – You can't remember what changed, when, or why.
No collaboration history – You don't know who did what, or how to undo it.
Version control exists to solve this: it gives you a single, shared history of your project. Every change is recorded, who made it is known, and you can go back to any point in time. No more "final_v3_final_REALLY" folders—just one place, with a clear timeline.
One sentence
Version control exists so teams can work on the same codebase without overwriting each other, losing work, or losing the story of how the project evolved.
The Pendrive Analogy in Software Development
How it used to work (and still does in some places)
Imagine a small team of developers in the early 2000s (or a student group today with no Git):
Developer A has the "main" copy of the project on their laptop.
Developer B needs to work on a feature. So they get the code from A—how?
Pendrive – A copies the project onto a USB stick; B copies it onto their laptop.
Email – A zips the project and sends it; B downloads and extracts.
Shared folder – A puts the project in
\\server\projectB copies it to their machine.
Then B works for a few days, changes files, and adds new ones. Meanwhile, A also changes the same files (bug fixes, refactors). Now:
B has their version (with their feature).
A has their version (with their fixes).
There is no single source of truth. Two (or more) copies have diverged.
To "merge" back:
B might copy their whole project back onto the pendrive (or send a zip). Now B's version overwrites A's—and all of A's changes disappear.
Or A and B sit together and manually compare files, copy-paste chunks, and hope nothing is missed. Slow, error-prone, and no record of what was merged.
That's the pendrive workflow: copy code here, copy code there, and "sync" by overwriting or by hand. It's like passing a single physical notebook back and forth—except everyone has a photocopy and nobody agrees which copy is the real one.
The "final, final_v2, latest_final" folder problem
Even one person runs into trouble without version control. You've probably seen (or made) folders like:
projectproject_backupproject_finalproject_final_v2project_latest_finalproject_latest_final_DONT_TOUCH
Why do these appear?
You're scared of breaking the "good" version, so you copy the whole folder and keep "backups."
You're not sure which copy has the latest fix or the right feature, so you keep adding suffixes.
There is no history—only a pile of copies. You don't know what's in
final_v2vslatest_finalunless you open and compare.
So even solo work becomes messy: overwriting, losing changes, and no clear timeline. The pendrive (or email, or shared folder) amplifies this when multiple people do the same thing with their copies.
Diagram idea: pendrive-based workflow vs version control workflow
Pendrive-based workflow (simplified):
Developer A (laptop) Pendrive / Email Developer B (laptop)
| | |
| ---- copy project ----->| |
| | ---- copy project -->|
| | |
| (A changes file X) | | (B changes file X)
| | |
| <---- copy project -----| (B overwrites A?) |
| | |
"Where did A's changes go?" | "Which copy is real?"
Version control workflow (simplified):
Developer A Central repo (e.g. GitHub) Developer B
| | |
| ---- push changes ---------------->| |
| |<------- pull changes -------------|
| | |
| (A changes file X) | (B changes file X) |
| ---- push ------------------------>|<------- push --------------------|
| | |
| One history. Merge. No overwrite. | Clear who changed what, when.
So: pendrive workflow = many copies, overwriting, no single history. Version control workflow = one shared history, merge instead of overwrite, and a clear record of who did what.
Problems Faced Before Version Control Systems
Overwriting code
What happens:
Developer A fixes a bug in utils.js. Developer B never got that file—they're still working on an old copy. B finishes their feature and copies their whole project back (pendrive/email/shared folder). Their utils.js doesn't have A's fix. So B's copy overwrites A's, and the bug fix disappears.
Why it hurts:
One person's work is silently replaced by another's. Nobody may notice until the bug reappears in production. There's no "merge"—only replace.
With version control:
Everyone works from the same history. When B integrates their work, the system merges changes: A's fix and B's feature can coexist. Overwriting is replaced by merge and review.
Losing changes
What happens:
You change a file, then realize you preferred the old behavior. Without version control, you only have:
Your current file (new version).
Maybe a backup folder from last week (old version).
You don't have every step in between. You can't answer: "What did this file look like last Tuesday?" or "What changed in the last 3 days?" So you lose the ability to go back or compare over time.
Why it hurts:
You can't safely experiment ("I'll try a big refactor") because undo means "restore from backup"—and backups are coarse and few. You also can't easily see what changed or when.
With version control:
Every significant change is committed with a message. You have a timeline of the project. You can revert a file (or the whole project) to any past commit. Nothing is "lost"—it's in history.
No collaboration history
What happens:
Three developers work on the same codebase via pendrives and zips. A bug appears. Questions nobody can answer:
Who changed this function?
When did they change it?
Why did they change it? (What was the context?)
There's no log of changes, no blame, no history. You only have the current files and maybe a few random backups. So debugging and code review are guesswork.
Why it hurts:
Teams can't coordinate or learn from past decisions. New joiners can't read the story of the project. When something breaks, you can't trace it back to a specific change or person.
With version control:
Every change is attributed (author, date) and described (commit message). You can blame a line (who last changed it), log a file (full history), and review what changed in a given time window. Collaboration has a paper trail.
Diagram idea: multiple developers editing the same file without version control
Day 1: File app.js (version 1) on A's laptop.
A copies to pendrive → B copies to laptop.
Day 2: A changes app.js (adds function validate()). → A's version = v2.
B changes app.js (adds function submit()). → B's version = v2' (different!).
Day 3: B copies "their" project back to pendrive.
A copies from pendrive to laptop.
→ A's laptop now has B's version. A's validate() is GONE.
→ No record of who had what. No merge. Just overwrite.
So: no version control = one person's edits replace the other's; with version control = both edits can be merged into one file with both functions, and the history shows who added what.
Diagram idea: timeline showing file versions getting lost or overwritten
Without version control:
Monday: app.js (v1) → copied to pendrive
Tuesday: A edits app.js (v2). B has v1.
Wednesday: B edits app.js (v2'). A has v2.
Thursday: B overwrites shared copy with v2'. → v2 (A's work) is LOST.
No snapshot of v2. No "undo." Only "who has a backup?"
With version control:
Monday: commit "initial app.js" → v1 saved in history
Tuesday: A commits "add validate()" → v2 saved in history
Wednesday: B commits "add submit()" → v2' merged with v2 → v3 in history
Thursday: Everyone has v3. History: v1 → v2 → v3. Nothing "lost."
So, without VCS = versions get lost or overwritten; with VCS = every version is in history and can be restored or compared.
Connecting the Pendrive Analogy to Real-World Team Collaboration
Why the pendrive problem is a team problem
The pendrive isn't the real villain—**having no single source of truth** is. In real teams, you see the same pattern even without physical USBs:
"I'll send you the updated file." – One person emails a file; the other overwrites their copy. Same overwrite risk.
"The latest code is on the shared driv.e" – Two people edit the same file; whoever saves last wins. Same loss of work.
"I have it on my machine, I'll merge it" – One person manually merges two diverged copies. Same pain, no history.
So the pendrive analogy is really about:
Multiple copies of the "same" project that diverge.
Syncing by overwriting or by manual merge.
No shared timeline of who changed what and when.
That's why it maps so well to real-world collaboration problems: whenever there's no one place that holds the full history, you get overwrites, lost changes, and no collaboration history.
What teams need instead
Teams need:
1. One place that everyone treats as the source of truth (e.g., a Git repo on GitHub/GitLab).
2. History – every change recorded with author, time, and message.
3. Merge – when two people change the same file, the system helps combine changes instead of overwriting.
4. Traceability – who changed what, when, and why (commits, blame, logs).
Version control (e.g. Git) provides exactly this. The pendrive workflow does not.
Why Version Control Became Mandatory in Modern Development
Scale and collaboration
Modern projects usually have:
Many people are touching the same repo (features, bugs, refactors).
Many files and many changes per day.
Remote teams (no passing a pendrive).
Doing this with pendrives, emails, and final_v2 folders is not scalable. Overwrites and lost work become constant. So version control isn't optional—it's the baseline for professional collaboration.
Expectations: review, rollback, and audit
Today we expect to:
Review changes before they land (pull/merge requests).
Roll back a bad deploy to a previous commit.
Audit what changed for a release or an incident.
None of that is possible without a recorded history of changes. So version control is also mandatory for process: code review, CI/CD, and compliance all assume "every change is a commit."
Natural transition from the pendrive world
So the story is:
1. Pendrive (and similar) workflows – Copy code around; sync by overwriting or manual merge; no shared history.
2. Pain – Overwriting code, losing changes, no collaboration history, no safe experiments, no blame or audit.
3. Solution – One shared repository with version control: history, merge, and traceability.
4. Result – Version control becomes mandatory in modern development.
If you've ever had a folder named final_v2 or lost someone else's fix by overwriting a file, you've already lived the problem. Version control exists so that doesn't have to happen anymore.
Happy versioning!
---
