Inside Git: How It Works and the Role of the .git Folder
Many beginners use Git daily but don’t know what Git is actually doing behind the scenes.
Let’s understand Git step by step, in simple words, without heavy theory.
The .git Folder :
When you run:
git init
Git creates a hidden folder called:
.git
This .git folder is the heart of Git.
It contains:
All commit history
Branches
Staging area
Git configuration
All Git objects
Important
If you delete the .git folder:
Your project becomes a normal folder
All Git history is lost
It is no longer a Git repository
Git Tracks Content, Not File Names
At a high level, Git does not track file names.
Git tracks file content.
Let’s understand with an example.
Example: Creating a File
You create a file:
hello.txt
With content:
Hello World
What Git Does Internally
Reads the content →
Hello WorldCreates a hash (unique ID) from the content
Stores the file using the hash, not the file name
Git remembers content, not hello.txt.
What If Two Files Have the Same Content?
file1.txt → Hello World
file2.txt → Hello World
Git sees:
Same content
Same hash
Git stores the content only once
Both files point to the same stored data
This saves memory and time.
What Happens When You Rename a File?
hello.txt → greeting.txt
Content is still:
Hello World
Git think: Nothing changed
Because:
File name changed
Content did NOT change
Git Stores Everything as Objects
Inside Git:
Files
Folders
Commits
Everything is stored as an object.
Each Git object:
Has a hash ID
Is saved only once
Cannot be changed after saving (immutable)
Git Objects:
Git mainly uses three types of objects.
1. Blob : File Content
A Blob stores:
- Only the content of a file
Important points:
Blob does not store file name
Same content = same blob
Two files with same content share one blob
2. Tree
Tree = Folder
A tree object represents:
A folder
List of files
List of sub-folders
Important:
Tree does not store file content
It stores:
File names
Which blob belongs to which file
Example
Your project:
project/
├── index.html
└── style.css
Git creates:
Tree (project)
├── index.html → blob hash
└── style.css → blob hash
3. Commit
A commit saves the current state of your project.
A commit stores:
Reference to a tree
Reference to parent commit
Author information
Commit message
A commit is a snapshot, not a diff.
How Git Tracks Changes:
What Happens When You Run git add
git add .
Internally, Git:
Reads file content
Creates blob objects
Generates hashes
Stores them in
.git/objectsUpdates the index (staging area)
Files are prepared, not committed yet.
What Happens When You Run git commit
git commit -m "message"
Internally, Git:
Reads the staging area
Creates tree objects
Creates a commit object
Links it to the parent commit
Updates the branch pointer
Snapshot is now saved permanently.
How Git Uses Hashes
Git uses hashes to keep data safe and correct.
A hash is a long string created from content.
Example:
Hello Git
↓
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
What Is a Hash?
A hash is like a fingerprint.
Same content → same hash
Small change → completely different hash
Example:
Hello → abc123
hello → xyz789
Even one letter change creates a new hash.
How Git Uses Hashes
Git uses hashes for:
File content (blob)
Folder structure (tree)
Commits
Every Git object:
Has its own hash
Is stored using that hash
Cannot be changed later
Why Hashes Make Git Safe
1. Detects File Changes
Content changes → hash changes
Git instantly knows something changed
2. Prevents Data Corruption
If:
Git data is edited manually
Files get corrupted
Hash mismatch tells Git data is broken
3. Protects Commit History
Each commit hash depends on:
File content
Tree
Parent commit
If you change an old commit:
Its hash changes
All future commits break
History tampering is detected