To understand the need for Version Control System(VCS), we need to know what problems arise for developers that led to the excessive use of VCS.

Life before VCS →

There was a world that existed before Version Control System came into the picture. The data was being shared using devices and technologies like pen drives, emails, version folders, CDs and DVDs for multimedia etc.
For example: If I am working on a project and I want someone else to see it, I will just store it in the pen drive and send it to them. They can insert it in their system and see it.

But what if the other person found some bugs, fixed it and returned it. How would I know where the fixes have happened. So in short, the track of the code is lost. This is only for two people, if multiple people are working then it will be a total chaos. Let’s say 50 people are working on the same project separately, there will have to be 50 separate copies of the same project and combining them would be next to impossible.

Why pendrives, emails, version folders were inefficient?

The most common problem with sharing code via these methods is the loss of version of the code. For example: if developer1 wrote a code and developer2 updated it, then the previous version of the code which written by developer1 is lost, there is no record of it.
The version folders like ‘final’ , ‘final_v2’ etc. can be made to track the version, but they still fail because to fix a bug you will need which version folder has the bug, which folder version is currently running. This is how the root analysis is lost. These methods can work upto 1 or 2 developers but fill fail badly after that.

The Core Problems with Pendrive-Based Sharing

1. No Single Source of Truth

Multiple copies of the same project exist, and each claims to be the “final” version. There is no authoritative version of the code.

2. Overwritten Work

Two developers work on the same file. One copies their version over the other, accidentally erasing hours of work.

3. No History

Once a file is replaced, older versions are gone forever. If a bug appears, there is no way to go back and check what changed.

4. No Accountability

There is no record of:

• Who changed what

• When it was changed

• Why it was changed

Debugging becomes guesswork instead of analysis.

5. Collaboration Does Not Scale

Pendrives and email attachments might work for one person or a small demo, but they completely fail for real teams working simultaneously.

How Version Control System solved the problem?

The idea behind VCS was very simple, if you want to track the changes in your project’s codebase, make a separate file that stores the changes made in the project. This file keeps track of the history of the project so that if someone else is also working simultaneously, they can see what changes were made by other collaborators.
In short, VCS is a tracker built to track changes in the code and store it in a separate file or directory on the local machine.

The problem of tracking is solved but the collaboration is still not possible between two people on different machines. The idea to solve this problem is again very simple, how about all the developers working on the project keep track of their code using the same tracker and put their codes on a central server that supports the tracker. This central server is known as a remote. Famous example of tracker and remote are GIT and GITHUB.

Single Source of Truth

A central repository becomes the official version of the project.

Complete History

Every change is saved. You can:

• View past versions

• Compare changes

• Roll back mistakes safely

Parallel Work with Confidence

Multiple developers can work on the same project at the same time using branches, without stepping on each other’s work.

Accountability & Transparency

Each change is linked to:

• An author

• A timestamp

• A message explaining the change

From Pendrives to Git

Tools like Git didn’t just improve file sharing—they fundamentally changed how software is built. What once required manual coordination, renaming files, and hoping nothing breaks is now automated, traceable, and reliable.

The pendrive problem wasn’t just about storage—it was about lack of control.

Version control exists because software development needs:

• Order over chaos

• History over guesswork

• Collaboration over isolation

About Remote (GitHub)

In version control, especially Git, a remote is a reference to a repository (folder) that is stored somewhere else, usually on the internet or on another machine. It allows developers to push their changes to a shared location and pull changes made by others.
In simple terms, a remote is the meeting point where everyone syncs their work.

Real-Life Analogy

Think of a remote as a shared Google Drive folder:

• Your local system → your personal workspace

• Remote repository → the shared, official copy

You work freely on your own machine, and when ready, you upload your changes so others can see and use them.

Conclusion ->

Version control systems were born out of necessity. The pendrive-based workflow exposed serious flaws in collaboration, reliability, and scalability. By introducing structured tracking, version control transformed software development from a fragile process into a disciplined engineering practice.

Problem with Pendrives and other systems →

• No tracking of code (Previous Version lost)

• Difficult to collaborate

• Numerous copies of the same project

• Humanly impossible to execute the final combining

• Difficult to ship the project to collaborators

• Impossible to counter merge conflicts

Instead of copying entire folders:

• Changes are tracked line by line

• Every update is recorded with metadata

• Conflicts are detected instead of silently overwriting work