How Git Version Control Works
Introduction
Git — the world’s most popular and powerful version control system — has transformed how developers collaborate and manage source code. But before Git, most of us relied on a simple (and chaotic) method to track changes — by creating multiple copies of files like:
blogPost_new,blogPost_backup,blogPost_final, and so on.
We’ve all been there — juggling dozens of file versions, getting confused about which one works, and struggling to remember why a file was changed. This old-school approach made it nearly impossible to manage projects efficiently.
That’s where Git saves the day. It’s a distributed version control system that allows developers to track every change, revert mistakes, collaborate seamlessly, and maintain a clean history of project evolution.
In this article, we’ll go beyond commands like git add, git commit, and git push — and explore how Git actually works under the hood, from states to internal architecture.
So grab your coffee, sit back, and let’s uncover the magic behind Git.
A Quick Introduction to Git
In simple terms, Git takes snapshots of your project at different points in time. Every time you save (or commit) your changes, Git records a snapshot and assigns it a unique SHA-1 hash — a secure 40-character identifier.
You can later view, compare, or revert to any snapshot as needed. This mechanism creates a reliable “timeline” of your project’s evolution.
The Core Concept: Git File States
At its core, Git operates through three main file states — Modified, Staged, and Committed.
If you include a remote repository (like GitHub), you can think of it as four states, since files may also exist remotely.
To make this clearer, let’s use a simple real-world analogy.
Imagine creating a photo album:
-
You take photos (but haven’t yet added them to the album).
-
You select and arrange the best ones on a table, ready to paste.
-
You glue them into the album and write captions describing each moment.
This process perfectly mirrors how Git manages files!
1. Modified State
You’ve made changes in your files, but haven’t saved them to Git yet.
These files live in your working directory, and Git is not yet tracking these modifications.
It’s like clicking new photos — you’re still deciding which ones are worth keeping. You can freely edit, delete, or redo your work at this stage.
2. Staged State
When you run git add, you tell Git to prepare these files for a commit.
They move into the staging area, where Git takes a snapshot of their current version.
You can still make further edits, and re-add updated files to the stage.
This stage is like laying out printed photos beside your album — they’re ready to go, but not yet glued.
3. Committed State
Finally, running git commit saves the staged snapshot into the Git directory (the .git folder).
This is like gluing your photos into the album and writing a short caption — the commit message — describing what changed and why.
💡 Tip: Always write meaningful commit messages.
For example:
✅ “Fixed payment API timeout issue”
❌ “Update code”
File Locations in Git
Each state corresponds to a different file location in Git’s internal structure.
| State | Location | Description |
|---|---|---|
| Modified | Working Directory | The files you’re editing locally. |
| Staged | Staging Area | Temporary storage for files ready to commit. |
| Committed | Git Directory (.git) | Permanent history of all commits. |
Let’s look at these areas in detail:
1. Working Directory
This is your project’s main folder — the one you open in VS Code or any IDE. It contains all editable files. Don’t confuse it with .git; that’s Git’s own system directory.
2. Staging Area
Also known as the index, the staging area lives inside the .git folder. It stores information about files queued for the next commit.
3. Git Directory
This is Git’s brain. It contains all committed files, branches, and version metadata. Whenever you clone a repository, this is what gets copied.
Git Workflow: Step-by-Step
Here’s how the Git workflow looks in action:
-
git clone— Copies the remote repository to your local machine. -
Edit or create files in the working directory.
-
git add <file>— Moves changes to the staging area. -
git commit -m "message"— Saves changes permanently to the local repository. -
git push— Uploads your commits to the remote repository.
Understanding git fetch, git merge, and git pull
When syncing with remote repositories, three commands are key:
-
git fetch: Downloads changes from the remote repository to your local repository, but does not update your working directory. -
git merge: Merges fetched updates into your local workspace. -
git pull: Performs bothfetchandmergein one step.
So why not always use git pull?
Because running git fetch first lets you review differences before merging. You can use:
-
git diff HEAD— To compare local commits with the fetched ones. -
git diff— To compare staged vs. working directory changes.
This helps prevent unwanted overwrites or merge conflicts.
Git Internals: Inside the .git Directory
When you initialize a Git repository (git init), a hidden folder named .git is created. This directory stores all data and metadata that Git uses to track your project.
Inside .git, you’ll find these key components:
| Component | Description |
|---|---|
objects/ | Git’s database — stores compressed, hashed file contents (blobs, trees, commits). |
refs/ | Stores pointers (references) to commit objects, such as branches and tags. |
HEAD | A file that points to the current branch’s latest commit. |
config | Contains repository-specific configuration settings. |
Git Plumbing Commands (Under the Hood)
Most Git users interact with porcelain commands like git add and git commit.
But under the hood, Git relies on plumbing commands — the low-level building blocks.
Here’s what happens behind the scenes:
-
When you stage a file (
git add), Git creates a blob — a binary representation of your file’s contents — and assigns it a SHA-1 hash. -
Multiple blobs form a tree, representing the directory structure.
-
A commit object references the tree, stores author information, commit message, and parent commit.
This chain of blobs, trees, and commits forms the entire project history.
Visualization
Each commit is a snapshot — not a diff — and Git efficiently compresses and stores only what’s needed.
Conclusion
Git is more than a version control system — it’s a time machine for your code.
From creating lightweight snapshots, using SHA-1 hashes, to managing commits through a smart reference system, Git’s architecture ensures both speed and reliability.
By understanding how Git actually works under the hood, you’ll not only become more confident with commands but also gain the ability to debug issues, resolve merge conflicts smartly, and manage projects at scale.
Whether you’re working solo or in a large team, mastering Git is one of the most valuable skills in a developer’s toolkit.
Comments
Post a Comment