Software development was not always as structured as it feels today. Before tools like Git became part of everyday programming, developers relied on pendrives, email attachments, and chaotic folder naming habits just to keep projects moving. This is why version control became necessary, and it is also why understanding how Git works internally matters.
1. 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
Without a proper system:
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
2. 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
HEADthe 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
Git stores information as objects. Knowing these gives you a clear mental picture.
Blob
Stores the raw content of a file.
It does not store the filename, only the data itself.
Tree
Represents a folder.
It stores filenames and points to blobs (files) or other trees (subfolders).
Commit
Represents a meaningful snapshot of your project.
A commit 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:
takes your file content
converts it into a blob
places it in the staging area
prepares it for the next commit
You are essentially saying:
“Remember this exact version of the file.”
When You Run git commit
Git:
creates a tree that represents the project’s state
creates a commit object that links to that tree
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
.git roughly holds:
objects→ blobs, trees, commitsrefs→ branches and tagsHEAD→ 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 idea:
.gitis where history livesGit 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.
Top comments (0)