Why Version Control Exists: The Pendrive Problem | Git & GitHub
The first question that arises for any developer is: Why do we want to study Git and GitHub? Work was happening before these tools existed, so what was the reason to create them?
To understand the answer, we have to look at how we used to work without them.
The Old Way: The Pendrive Chaos
Imagine a developer named Ahmad who runs code on his local machine. He saves his code on a pen drive and shares it with his teammate so they can use it.
When the teammate views the code, they make some changes and return the updated code via the pen drive back to Ahmad.
Now, Ahmad faces a dilemma. He doesn't know what is happening in the code:
Which changes were made?
Where did the changes occur?
After a while, the teammate realizes there is an issue in the code and fixes it. Again, they have to give Ahmad the pen drive. This cycle continues, and it creates a massive headache.
Figure 1: The confusion of manual collaboration without version control ( Git ).
The Problems They Faced
This manual process created several critical issues:
Unknown Changes: When the teammate made changes, Ahmad didn't know what changed. When Ahmad made changes, the teammate was equally lost.
No Tracking: There was no way to know which files were changed or deleted.
Physical Limitations: Every time someone made a change, they had to physically share the pen drive.
No Collaboration: Both developers couldn't work simultaneously; collaboration was extremely difficult.
No History: There was no record of code changes, meaning they couldn't retrieve old versions if something broke.
Solution Part 1 : Git (Local Version Control)
When developers identified this problem, they built a Code Tracker which they named "Git".
Actually, Git is a Version Control System (VCS). There are other VCS options in the market like Mercurial or Apache Subversion (SVN), but Git is the most popular.
What Git does locally:
It tracks all changes in the code.
It shows who made what changes and when.
It displays a history of modified files.
It can be used by a single developer on their local machine.
This solved the tracking problem. However, there was still a big problem remaining: The pen drive still had to be shared.
There was confusion about which version was the "latest," no central backup existed, and code was stuck on local machines.
Solution Part 2 : Remote Repository (GitHub)
To solve the collaboration issue, they built a Single Source Solution where all developers could push their updated code to a central server. They named this "GitHub".
In this context, what we call a "server" is referred to as a Remote Repository.
Figure 2: GitHub acting as a central hub for developers to push and pull code.
What GitHub (Remote) does :
It acts as a central server (in the cloud) for collaboration.
All developers connect to it simultaneously.
When a developer updates code, they "Push" it to GitHub.
Other developers can easily view the latest code and "Pull" it.
Everyone instantly knows what changed, and a complete backup stays safe in the cloud.
With this, the collaboration problem was completely solved.
Important Clarification: Git vs. GitHub
Nowadays, many people write "Learned GitHub" on their resume, but this is technically wrong.
❌ "Learned GitHub" = WRONG
✅ "Learned Git" = CORRECT
Why?
GitHub is just a hosting service (a platform) where you store code. Learning GitHub just means clicking buttons.
Git is the complete Version Control System (the tool) that needs to be learned. It requires understanding commands (init, add, commit), concepts (staging, history), and workflows.
In Simple Words:
Git = Local Version Control System (On your computer).
GitHub = Remote Repository Hosting (On the internet).
Who Built Git?
Git was created by Linus Torvalds in 2005.
He was working on the Linux Operating System. At that time, Linux was growing rapidly, and thousands of developers were working together. Tracking code became very difficult. They were using other systems (like SVN), but they were slow.
Linus decided to build his own system that would be fast, distributed, and reliable. He built Git in just a few weeks as a side project!
` Fun Fact: "Git" is British slang for "an annoying or foolish person." Linus jokingly gave it this name because Git was quite strict and complicated. `