Why Version Control Matters: Overcoming the Pendrive Dilemma and Learning Git Mechanics

Source: Dev.to

Why Version Control Exists: The Pendrive Problem

Life Before Version Control

Managing projects used to be a gamble. Developers made multiple copies of the same project, shared files manually, and hoped nothing important got lost. There was no dependable way to see who made a change, when it happened, or what exactly was modified. Teams basically worked with crossed fingers.

The Pendrive Scenario

Imagine a team working without Git:

• Developer A completes some work
• Saves it to a pendrive
• Hands it to Developer B
• Developer B edits the project and passes it to Developer C

Meanwhile, Developer A keeps coding on an older copy. Suddenly the team has several “latest” versions, and nobody is sure which one is truly correct.

The same chaos played out through:

• sending code via email
• exchanging ZIP files

endlessly duplicating project folders:

project-final
project-final-v2
project-latest-final
final-really-final

It sounds humorous now, but this was normal practice.

Real Problems Without Version Control

• Files were overwritten without warning
• Stable working code disappeared permanently
• There was no shared history of changes
• Nobody could clearly explain who changed what or why

Collaboration became risky. When two people edited the same file, they compared code manually, line by line. Errors slipped in, deadlines stretched, and confidence in the codebase faded.

Why This Does Not Work Today

Modern development involves:

• Teams spread across locations
• Constant updates
• Long‑term maintenance
• Experimentation with features

A pendrive‑style workflow collapses immediately under this pressure. Teams need:

• Reliable project history
• Automatic change tracking
• Safe collaboration
• Quick recovery from mistakes
• Clear version timelines

So version control stopped being optional. It became essential for professional work, education, open‑source contributions, and any serious coding effort.

Without Version Control:
Multiple copies → confusion → lost history → accidental overwrites

With Version Control:
Everyone works → changes tracked → history preserved → collaboration stays safe

---

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

Git Does More Than Store Files

Git is not simply a storage tool. It records complete project history in a structured way. Understanding what happens inside your repository makes Git far less mysterious.

The .git Folder

When you run:

git init

Git creates a hidden folder named .git. This folder is the brain of your project. It stores:

• All commits
• Branch information
• References like HEAD
• The internal object database
• Important metadata

Delete the .git folder, and your project turns into a normal folder with no history. That alone shows how critical it is.

Git’s Building Blocks: Blob, Tree, Commit

Blob

• Stores the raw content of a file.
• Does not store the filename, only the data itself.

Tree

• Represents a folder.
• Stores filenames and points to blobs (files) or other trees (subfolders).

Commit

• Represents a meaningful snapshot of your project.
• Stores:
  • A reference to a tree (project state)
  • Author details and time
  • A message
  • A link to the previous commit

These links form your project’s history.

How Git Tracks Changes

Instead of constantly comparing files line by line, Git identifies content using hashes. Each saved version receives a unique SHA‑1 hash. Even a tiny change produces a completely different hash. This ensures:

• Strong integrity
• Reliable history
• Protection from silent corruption

Every commit is verifiable.

What Actually Happens During git add and git commit

When You Run git add

Git:

1. Takes your file content
2. Converts it into a blob
3. Places it in the staging area
4. Prepares it for the next commit

You are essentially saying: “Remember this exact version of the file.”

When You Run git commit

Git:

1. Creates a tree that represents the project’s state
2. Creates a commit object that links to that tree
3. Connects it to previous commits

This builds a timeline:

Commit A → Commit B → Commit C → HEAD

Each commit is chained, preserving history securely.

A Simple Structural View

The .git directory roughly holds:

• objects → blobs, trees, commits
• refs → branches and tags
• HEAD → points to the current branch

Commit
 └─ Tree
     ├─ Blobs (files)
     └─ More Trees (subfolders)

The Mental Model That Makes Git Easier

You do not need to memorize every command. Understand the core ideas:

• .git is where history lives
• Git stores snapshots, not just files
• Blobs hold content
• Trees organize structure
• Commits link everything into history

Once this picture clicks, Git becomes predictable, logical, and far more comfortable to use.