Version Control: Solving the Pendrive Issue

Hey, I know you’ve probably been in this situation before…

You and your friends decide to start a “big project.” Everyone gets excited, you choose the idea, tech stack, and assign roles:

“Bro, you set up the project structure.”
“I’ll do the login feature.”
“I’ll handle the Home Page!”

Life is good… until you actually start writing code.

At the start, this will work fine

You initialize the project
Export it in pendrive
Zip it and share it via email
Uploads it to Google Drive
Everyone downloads it and stores it locally

At the time when chaos starts

But when the codebase starts to increase, the bugs and errors also start to increase.

“One friend I had completed the login feature, everyone, I am updating the latest codebase on a pendrive.”

“Another friend will say no, I am currently working on it and keeping it as a reference.”

So, we all decided to create a new folder to tackle this issue. At that time, we were happy that everyone could now work at their own pace. But the new problem arises as that folder didn’t stay final anymore, there were new folders with the name:

“ProjectName_finallllllll”

“ProjectName_finalVersion”

“ProjectName_Grandfinal”

etc..

The Real Problem: No History, No Traceability

Let’s say one friend adds a nice feature. What happens next?

Everyone deletes their old local codebase and copy-pastes the new folder. Nice and simple.

But here’s the catch:
Nobody knows what changed — which file, which line, or which folder.

And if that new feature has a bug?

There is no going back because there’s no history. No “undo,” no “previous version,” no “compare changes,” no “rollback.”

Turing Point

Linus Torvalds (Creator of Linux) also faced some problems like this while creating Linux so he made a product to solve this problem, which is a tool to track changes, store history, and allow multiple developers to collaborate safely.

He called it Version Control — specifically Git.

So What is Git, Really?

Imagine Git as a time machine for your code.

Every time you make a change, Git takes a snapshot of the codebase, keep in mind

Which files changed? Which lines changed
Why they changed, when they changed

Now you can install Git on your local machine and let it do its magic. Whenever you initialize Git inside a project, it starts keeping snapshots of your code. Every time you make changes and commit, Git compares the new code with the old snapshot and stores only the differences.

But here’s an interesting question:

“If Git stores snapshots on everyone’s local machines, how do developers actually collaborate?”

Because if everyone kept their own snapshots locally, it would just become a smarter version of the pendrive problem — everyone would have their own history, but nobody would share it with others.

So to solve this their will be a central server where we can upload the code that will be taken as the source of truth, so that every snapshot will get compared with the server codebase. So whenever some one try to push the code, the snapshot will be compared with the codebase on the server, by which there will be no inconsistency.

So whenever someone tries to push their changes, Git compares their local snapshot with the snapshot stored on the server. If everything matches up (meaning nothing conflicts), the push succeeds.

These central servers are what we know today as platforms like

GitHub
GitLab
Bitbucket
Azure Repos etc…

Git is a game-changer in the world of tech. If you are new, you should get familiar with the git, as that will help you in your software engineer career path.

Thanks for reading, and see you in the next blog!

Peace ✌️ and Happy Learning!