Why Version Control Exists: The Pendrive Problem
Most beginners start with a simple belief:
“I’ll just keep my code in a folder. That’s enough.”
It feels reasonable. You write files, hit save, and move on. Why add another tool?
To see why this mindset breaks fast, let’s rewind to an old-school way of working.
Imagine Harsh, Hitesh, and one more friend building a simple web app for their college club. There’s no Git. No GitHub. Just one USB drive.
Day 1: Harsh builds the landing page and copies the project to the USB.
Day 2: Hitesh takes it home to add a signup form.
Day 3: The third friend tweaks fonts and spacing.
Only one person can work at a time. The USB becomes the “owner” of the project.
At first, it feels manageable. But by the end of the week, the mess begins.
Hitesh doesn’t want to risk deleting anything, so he duplicates the folder. The third friend does the same. Now the USB looks like this:
ClubApp
ClubApp_Final
ClubApp_Final_2
ClubApp_Final_Please_Work
Harsh plugs it in and just stares. Which one is real?
Meanwhile, Harsh fixed a login bug on his laptop while the USB was away. When it comes back, he copies everything over… and wipes out his own fix. It’s gone. No undo. No history.
Then the app crashes.
Someone removed a critical line.
Harsh asks Hitesh. “Not me.”
He asks the other friend. “Not me.”
There’s no trail. No record. No way to rewind. They burn hours hunting a single missing line.
This chaos is annoying with three students. Now scale it to a real company.
Thirty or fifty developers. Different cities. Different time zones.
You cannot pass a USB from Delhi to Berlin.
You cannot email a full project ten times a day.
You cannot risk losing weeks of work because someone overwrote a folder.
That’s when people say, “We’ll just use Google Drive.”
Shared folder. Everyone edits. Modern problem solved, right?
Not really.
Harsh and Hitesh open the same file, dashboard.html.
Harsh changes the sidebar.
Hitesh changes the footer.
Both reconnect to the internet.
Drive panics and creates:
dashboard.html
dashboard (Conflicted Copy).html
dashboard (Hitesh’s Laptop).html
Now someone has to open all three, compare line by line, and merge them manually. One mistake and the page breaks.
Another problem: half-finished updates.
Harsh is adding a feature that touches four files. Three sync. His Wi-Fi drops before the fourth. Hitesh pulls the project and runs it. It crashes because the code is incomplete.
Drive also tells you who edited a file, but not why.
“Edited by Harsh at 6:40 PM.”
Did he fix a bug? Remove security logic? Change a color? You have to open the file and guess.
This is exactly why version control exists.
Git isn’t just storage. It’s memory for your project.
Every meaningful change becomes a snapshot with a message:
“Fix sidebar overlap on mobile”
“Add form validation”
“Remove unused API call”
You don’t just see when something changed. You see the story of why it changed.
Git works at the line level.
If Harsh edits line 15 and Hitesh edits line 90, Git merges them automatically. No duplicates. No chaos.
And updates are atomic.
Your teammate only receives your work when it’s complete. Not half-built. Not broken.
Think of Git like a game save system.
Before a risky boss fight, you save.
If you lose, you reload.
In coding, before experimenting, you commit.
If everything breaks, you roll back.
No more:
“Final_v7” folders
Silent overwrites
Blame games
Lost work
One clean project. Full history. Safe collaboration.
Version control exists because people make mistakes and teamwork is messy.
Git turns that mess into an organized timeline where hundreds of developers can work at once without stepping on each other.
So the next time you feel lazy to type git commit, remember this:
You don’t want to be the person scrolling throughClubApp_Final_Really_Last_Please_Work
at 3 in the morning.
