DEV Community: saiyam gupta

# Why Version Control Exists: The Pendrive Problem

saiyam gupta — Sat, 10 Jan 2026 12:00:40 +0000

Before Git, GitHub, and modern tools, developers still wrote code — but the way they managed it was painful.

This blog explains why version control exists, using a very relatable story: the pendrive problem. If you understand this problem, you’ll instantly understand why version control systems became mandatory in software development.

Life Before Version Control

Once upon a time (not very long ago), developers managed code using:

Pendrives
Emails
Shared folders
File names like:
- final.zip
- final_v2.zip
- final_latest.zip
- final_latest_REAL.zip

Sound familiar? 🙂

The Pendrive Analogy

Imagine this situation:

Developer A writes code and saves it on a pendrive
He gives the pendrive to Developer B
Developer B makes changes
Meanwhile, Developer A also updates the same file

Now the pendrive comes back.

👉 Whose code is correct?
👉 Which version is latest?
👉 What got overwritten?

No one knows.

This is the pendrive problem.

Problems Faced Without Version Control

1. Overwriting Code

Two people edit the same file.
One person’s work replaces the other’s.

💥 Work is lost forever.

2. No Change History

Questions developers couldn’t answer:

Who made this change?
Why was this line added?
When did this bug appear?

There was no timeline, only confusion.

3. Fear of Making Changes

Developers were scared to:

Refactor code
Try new features
Fix bugs

Because:

“What if I break something and can’t go back?”

4. No Real Collaboration

Teamwork meant:

Waiting for someone to finish
Passing pendrives or emailing zip files
Manually copying code

This does not scale for real teams.

Folder Chaos Timeline

project/
 ├── final/
 ├── final_v2/
 ├── final_latest/
 ├── final_latest_REAL/
 └── final_latest_REAL_2/

Instead of progress, there was chaos.

Multiple Developers, One File (Without Version Control)

Dev A → file.js (version A)
Dev B → file.js (version B)
Dev C → file.js (version C)

Result: Conflicts, overwrites, lost work

No system. No safety.

Enter Version Control Systems (VCS)

Version control systems were created to solve exactly these problems.

They allow:

Multiple developers to work together
Automatic tracking of changes
Safe experimentation
Complete history of the project

Instead of pendrives, we now use repositories.

How Version Control Fixes the Pendrive Problem

Version Control Workflow

Central Repository
   ↑      ↑      ↑
 Dev A  Dev B  Dev C

Each developer:

Works independently
Saves changes safely
Merges work without overwriting others

What Version Control Gives Us

✅ No lost code
✅ Full change history
✅ Easy rollback
✅ True collaboration
✅ Confidence to experiment

This is why version control is mandatory in modern development.

Why Git Became the Standard

Git solved the pendrive problem completely:

Distributed system (everyone has a copy)
Fast and reliable
Designed for teamwork

That’s why tools like GitHub, GitLab, and Bitbucket exist today.

Final Thoughts

The pendrive problem wasn’t about storage — it was about control, safety, and collaboration.

Version control systems turned chaos into structure.

If you understand this problem, you understand why Git exists.

And once you use version control, there’s no going back.

Happy coding 🚀

# Inside Git: How It Works and the Role of the `.git` Folder

saiyam gupta — Sat, 10 Jan 2026 11:54:47 +0000

Most developers use Git every day, but very few understand what Git is actually doing behind the scenes. This blog is not about memorizing commands — it’s about understanding Git.

If you can picture how Git works internally, everything else (commands, errors, conflicts) becomes much easier.

How Git Works (Big Picture)

At its core, Git is a smart storage system.

Instead of thinking:

“Git tracks my files”

Think this way:

Git stores snapshots of your project and connects them together.

Each snapshot is saved permanently and identified using a unique hash. All this data lives inside one folder:

👉 the .git folder

What Is the `.git` Folder and Why Does It Exist?

The .git folder is the brain of Git.

It is created when you run git init
It stores your entire project history
It remembers every commit, branch, and change

If you delete the .git folder:

Your project becomes a normal folder — Git forgets everything.

So even though you work with visible files, Git only cares about what’s inside .git.

Structure of the `.git` Directory (Simple View)

.git/
├── objects/   → All saved data (snapshots)
├── refs/      → Branch pointers
├── HEAD       → Where you are right now
├── index      → Staging area
├── config     → Repo settings
└── logs/      → Movement history

You don’t need to memorize this. Just remember:

objects store data
index is staging
HEAD tells Git your current position

Git Objects: The Core Building Blocks

Git stores everything as objects. There are only three you really need to understand.

1. Blob — File Content

A blob stores the actual content of a file.

Important details:

No file name
No folder info
Same content = same blob

Think of a blob as:

“Pure file data, nothing else.”

2. Tree — Folder Structure

A tree represents a directory.

It stores:

File names
Folder names
Links to blobs and other trees

Think of a tree as:

“How everything is arranged.”

3. Commit — Project Snapshot

A commit is a snapshot of your project at a moment in time.

A commit stores:

A reference to a tree
Parent commit(s)
Message and author info

Think of a commit as:

“This exact version of the project.”

How Commits, Trees, and Blobs Are Connected

Commit
  ↓
 Tree
  ↓
Blobs

Example:

Commit
 └── Tree
     ├── index.html → Blob
     └── app.js     → Blob

This design is why Git is fast and efficient.

How Git Tracks Changes (Key Idea)

Git does not store line-by-line differences like older systems.

Instead:

Git stores full snapshots, but reuses unchanged parts.

If a file doesn’t change:

Git reuses the same blob
No extra space is wasted

That’s how Git stays fast even with thousands of commits.

What Happens Internally During `git add`

When you run:

git add file.txt

Git does this internally:

Reads the file content
Converts it into a blob
Stores the blob in .git/objects
Updates the index (staging area)

Flow:

Working Directory
      ↓ git add
Staging Area (index)
      ↓
Blob stored in .git/objects

At this point:

The file is staged
No commit exists yet

What Happens Internally During `git commit`

When you run:

git commit -m "message"

Git performs these steps:

Creates a tree from staged files
Creates a commit object
Links it to the previous commit
Moves HEAD forward

Flow:

Staging Area
   ↓ git commit
Tree created
   ↓
Commit created
   ↓
HEAD updated

How Git Uses Hashes (Why Git Is Trustworthy)

Every Git object is named using a hash.

This gives Git superpowers:

Same content → same hash
Small change → completely new hash
Corruption is easy to detect

In simple words:

Git knows if anything has been altered or damaged.

This is why Git history is reliable.

The Mental Model to Remember

Don’t memorize commands. Remember this instead:

Git stores objects
Objects are connected by references
Commits are snapshots, not diffs
HEAD tells Git where you are

Once this clicks, Git feels logical instead of confusing.

Final Thoughts

Understanding Git internally makes you a stronger developer.

You’ll:

Debug issues faster
Handle merges confidently
Explain Git clearly in interviews

Most importantly, Git will finally make sense.

Happy learning 🚀

Git for Beginners

saiyam gupta — Sun, 04 Jan 2026 17:53:48 +0000

Git for Beginners: Simple, Clear, and Practical Guide

If you are learning development, Git is not optional — it is essential. Don’t worry though. Git is much simpler than it looks once you understand the basics.

This blog explains Git in a human, easy, and practical way, with simple examples you can actually use.

What is Git?

Git is a tool that helps you save, track, and manage changes in your code.

In simple words:

Git remembers every version of your project so you can move forward or go back anytime.

Think of Git like:

A save button with history
A backup for your code
A tool that lets many people work together safely

Why Git is Used?

Git makes a developer’s life easier.

You can undo mistakes
You can see who changed what
You can work on new features without breaking existing code
You can collaborate with a team smoothly

That’s why almost every company uses Git.

Core Git Concepts (Very Simple)

Repository (Repo)

A repository is just your project folder that Git is tracking.

Inside it, Git stores all change history.

Commit

A commit is a saved version of your code.

You can think of it as:

“I like the current state of my project. Save it.”

Example:

Added homepage UI

Branch

A branch is a separate copy of your code to work safely.

main → stable code
feature-login → new work

Branches let you experiment without fear.

HEAD

HEAD tells Git where you are right now.

It points to the current commit you are working on.

Git’s 3 Important Areas

Working Directory → Staging Area → Repository

Working Directory: where you edit files
Staging Area: where you prepare files
Repository: where commits are stored

Common Git Commands (You’ll Use These Daily)

Start Git in a Project

git init

Check What’s Changed

git status

Add Files to Git

git add index.html
git add .

Save Your Changes

git commit -m "Initial setup"

See Past Saves

git log --oneline

A Real Developer Workflow (From Scratch)

mkdir my-project
cd my-project
git init

Create a file → edit it → then:

git add .
git commit -m "Add first version"

Make changes → repeat the same steps.

This is exactly how developers use Git daily.

How Git History Looks

Commit A → Commit B → Commit C (HEAD)

With branches:

main ── A ── B
          \
           C ── D (feature)

Project Structure (Simple View)

Project Folder
 ├── Your files (working directory)
 └── .git (Git history)

Final Thoughts

Git is not hard — it’s just new.

If you understand:

what a commit is
how to add and save changes
and the basic workflow

You already know 80% of Git.

Practice a little every day, and Git will feel natural very quickly.

Happy coding 🚀

DEV Community: saiyam gupta

# Why Version Control Exists: The Pendrive Problem

Life Before Version Control

The Pendrive Analogy

Problems Faced Without Version Control

1. Overwriting Code

2. No Change History

3. Fear of Making Changes

4. No Real Collaboration

Folder Chaos Timeline

Multiple Developers, One File (Without Version Control)

Enter Version Control Systems (VCS)

How Version Control Fixes the Pendrive Problem

Version Control Workflow

What Version Control Gives Us

Why Git Became the Standard

Final Thoughts

# Inside Git: How It Works and the Role of the `.git` Folder

How Git Works (Big Picture)

What Is the .git Folder and Why Does It Exist?

Structure of the .git Directory (Simple View)

Git Objects: The Core Building Blocks

1. Blob — File Content

2. Tree — Folder Structure

3. Commit — Project Snapshot

How Commits, Trees, and Blobs Are Connected

How Git Tracks Changes (Key Idea)

What Happens Internally During git add

What Happens Internally During git commit

How Git Uses Hashes (Why Git Is Trustworthy)

The Mental Model to Remember

Final Thoughts

Git for Beginners

Git for Beginners: Simple, Clear, and Practical Guide

What is Git?

Why Git is Used?

Core Git Concepts (Very Simple)

Repository (Repo)

Commit

Branch

HEAD

Git’s 3 Important Areas

Common Git Commands (You’ll Use These Daily)

Start Git in a Project

Check What’s Changed

Add Files to Git

Save Your Changes

See Past Saves

A Real Developer Workflow (From Scratch)

How Git History Looks

Project Structure (Simple View)

Final Thoughts

What Is the `.git` Folder and Why Does It Exist?

Structure of the `.git` Directory (Simple View)

What Happens Internally During `git add`

What Happens Internally During `git commit`