Why Version Control Exists: The Pendrive Problem
Simple guy learning web development
This article tries to answer questions such as :-
Why Version Control Exists.
The Pendrive Analogy in Software Development.
Problems Faced Before Version Control Syste.
Introduction
We often encounter the term "Version Control" described in complex ways, but to grasp its purpose, we need to consider what happens without it. Imagine someone asking for your help with a technical task, like setting up electrical wiring or configuring a mobile or laptop for the first time. If you're physically present, it's manageable, but if you're guiding them remotely, they might do something different and blame you for not giving proper instructions. This same scenario, frustration, and chaos occur on a larger scale in software development when diverse developers collaborate on a project. To manage this chaos and confusion, version control is essential for tracking the development process and assigning accountability to developers.
The Scenario: The Manual Exchange
Consider a simple scenario with two developers, A and B.
Developer A encounters a significant error while writing code and needs assistance.
If B is nearby: B can simply look over and help fix it. Simple.
The Reality: B is far away.
To get help, A copies the code onto a pen drive and sends it to B. B fixes the error on their machine and returns the pen drive with the corrected code.
The Immediate Problems
This seemingly simple exchange creates issues for A:
The File Duplicate Trap: A now has two files: Code_With_Error and Code_Fixed.
The "Black Box" Fix: If the code is small, A might notice the changes. But with thousands of lines, A can't easily identify what B altered.
Result: A applies the fix but never learns what went wrong, risking the same mistake in the future.
The Escalation: The Bottleneck
As A and B continue exchanging the pen drive, the project grows. They realize they can't track which lines do what anymore. To avoid overwriting each other's work, they establish a rule:
"Only one person holds the code at a time."
When A receives the pen drive, he deletes his old code and replaces it with B's version. B does the same when they get it.
The Consequences:
Zero Collaboration: They can't work simultaneously.
No Fallback: If they decide a previous feature was better, they can't revert. That code is lost when they swapped the pen drive.
The Solution: The Tracking System
To resolve this chaos, A and B need a system in their workflow.
First, they need a Tracker. Instead of blindly swapping files, they require a tool that monitors the code and reports:
What changed? (The exact lines).
Who changed it? (Was it A or B?).
This resolves the "learning" problem—A can now see exactly what B fixed. But the collaboration issue remains.
The Evolution: The Centralized Source (Remote)
To address the collaboration problem, a Single Source of Truth is needed.
Instead of the code residing on a moving pen drive, the official code is stored in a Centralized Source (a server).
A downloads the code from the Central Source.
A makes changes and sends them back to the Central Source.
The Tracker updates the history, informing everyone: "Developer A made these specific changes."
Now, B can see those changes immediately without waiting for a physical handover.
Summary
Version Control System (VCS): The "Tracker" that monitors changes, history, and authorship.
VCS Remote (or Remote): The "Centralized Source" where the source of truth and tracking history reside.
Version control exists to protect us from ourselves. It shifts our mindset from "I hope I don't break this" to "I can experiment freely because I can always go back."