Inside Git: How It Works and the Role of the .git Folder
MCA graduate | Software developer documenting my learning journey and sharing beginner-friendly tech concepts.
Introduction
There is a system operating in the background when we use Git commands like git init, git add, or git commit. Our project is kept organised thanks to this system. Our work is stored there. monitors the modifications we make to our project. Many people use Git by entering commands into the computer. Few people actually understand what Git is doing. Git is working hard behind the scenes to support our project. Git commands like git init and git commit are frequently used. Typically, we don't consider the assistance that Git provides.
Because it contains all the data that Git requires, this .git folder is crucial to your project. Commits, branches, configuration, and logs are all stored in the git folder. It contains all the resources Git requires to assemble your project at any time. Git occasionally uses the .git folder to recall the appearance of your project. The core of your repository is the git folder. Git's compatibility with your project is crucial.
Before we deep dive into Git internals, objects, and commit branches, it’s important to know what the .git folder contains, how git tracks your files, and how this folder is the core of the entire Git Workflow.
How Git Works Internally
Commits, files, branches, and logs are all stored as objects inside a unique hidden directory known as the.git folder in Git, which functions similarly to a content-addressable database. The repository's brain is located in this.git folder. Git reads and writes data to this folder each time you create a commit, switch branches, or stash changes. Without it, your project is just a typical file directory. It gives git the ability to manage branches, track history, restore previous iterations, and guarantee that your work is never lost.
The git folder exists because Git needs a dedicated space to store:
The complete commit history
Snapshot of your files
Branches references
Stashes, tags, and logs
Local Configuration and Hooks
Understanding the .git folder
When you run the git init, Git creates a hidden directory called .git. This folder is the “brain” of the project. While the folder looks complex, most of its magic happens within the objects directory. This is Git’s database, and it relies on the four main types of objects to keep track of the work.
The Content: Blobs
Blob is the short form of “Binary Large Object”. When you save the file in Git, it doesn’t care about the filename or the permissions; it only care about the permissions; it only cares about the content.
What is it: A snapshot of a single file’s content at a specific point in time.
How it works: If you change one word in a file and commit it, Git creates a brand-new blob for the version.
Key Details: Blob don’t store the filename. That’s handled by the next object.
The Directory: Trees
If Blobs are the files, Trees are the folders. A Tree object maps filenames to Blobs and allows Git to group files.
What it is: A list of filenames and their corresponding Blob IDs (hashes).
Nested Structure: A Tree can also point to other Trees, which is how Git represents subdirectories.
The Snapshot: Commits
A commit object is the glue that ties everything together. It represents a specific version of your entire project.
What it contains:
1. A pointer to the top-level Tree ( the root folder)
2. Metadata: Author, date, and commit message.
3. A pointer to the Parent Commit ( the version that came before it). This creates the “chain” or history
The Human Label: Tags
A tag is a label attached to a specific commit. Unlike a branch (which moves as you add new commits), a tag stays put. These are typically used for the version released.
Relationship Between Commits, Trees, Blobs
What happens internally during git add and git commit
1. git add: The Hashing Phase
When you run git add <file name>, git focuses on the content of that specific file.
Create a Blob: Git reads the file’s content, adds a header ( identifying it as a “blob”), and compresses it using zlib.
Generate a Hash: It includes a unique SHA-1 hash(40 character) based on the compressed content.
Store the Object: It saves this file in .git/object/. The first two characters of the hash become a folder name, and the remaining 38 become the filename.
Updates the Index: This is the crucial part. Git updates the file named
.git/index. This binary file acts as a map, listing the filename (e.g.,readme.md) and the specific hash of the blob you just created.
Key takeaway: After
git add, your file content is already safely inside the.gitfolder, but it has no "history" or commit message attached to it yet.
2. git commit: The Snapshot Phase
When you run git commit -m "Message", Git takes the map in the Index and turns it into a permanent part of the project's history.
Creates the Tree(s): Git looks at the current Index and builds Tree objects. If your project has subfolders, Git creates a tree for each folder. The top-level Tree represents the root of your project at this exact moment.
Creates the Commit Object: Git generates a new object containing:
The hash of the top-level Tree.
The hash of the Parent Commit (the previous version).
Your name, email, timestamp, and the commit message.
Calculates the Commit Hash: Just like the blob, the entire commit object is hashed. This becomes your "Commit ID."
Updates the Branch Pointer: Finally, Git moves your current branch pointer (like
main) to point to this new Commit ID.
How Git Tracks Changes
Every Object in the .git folder is named using a unique 40- character string called a hash (calculated via the SHA - 1 algorithm).
Hash = SHA -1 (Content + metadata)
Because the name is derived from the content, if a single bit of data changes, the hash changes, and git knows it’s a new version.
Git uses a Hash to Ensure Integrity
In Git, hashes are the foundation of data integrity. They act like a digital seal on a container: if someone tries to peek inside or change a single character, the seal breaks, and Git immediately knows.
Git uses the SHA-1 (Secure Hash Algorithm 1) to generate a unique 40-character fingerprint for every piece of data in your project.
Stop Memorising Git: How to See Your Project Like Git Does
If you memorise commands like git push or git rebase without a mental model, you’re just memorising magic spells. If the spell fails, you’re lost. Here is the mental model that makes Git intuitive.
1. The Three States (The Locations)
Imagine your project exists in three different "rooms." Moving data in Git is simply the act of moving items between these rooms.
The Working Directory (The Sandbox): This folder on your computer represents your current workspace. Feel free to organise, delete, or experiment here, as Git is monitoring changes but hasn't committed or "saved" anything yet.
The Staging Area/Index (The Loading Dock): This is where you prepare your next version. You don’t have to ship everything in your sandbox; you pick and choose exactly which files are ready to be "photographed."
The Repository (The Vault): Once you commit, Git takes a high-resolution snapshot of the Loading Dock and locks it in the vault forever.
2. Commits are "Snapshots," not "Instructions"
A common mistake is thinking a commit says: "Add three lines to file A." In reality, a commit says: "This is exactly what the entire project looked like at 2:00 PM on Tuesday."
Think of a commit as a Polaroid photo.
If you want to see what the project looked like last week, you don't "undo" your work; you simply tell Git to show you a different Polaroid.
Because each Polaroid also records which photo came before it, they form a string—a Timeline.
3. Branches are just "Sticky Notes"
This is the "Aha!" moment for most learners. In other systems, a branch is a heavy, separate copy of the code. In Git, a branch is just a removable sticky note stuck onto a specific Polaroid.
When you are on the
mainbranch, you are just standing in front of the Polaroid that has the "main" sticky note on it.When you make a new commit, Git moves the sticky note forward to the new photo automatically.
HEAD is just a pointer that says, "You are standing here."
4. Merging is "Finding the Common Ancestor"
When you merge feature-A into main, Git doesn't just smash the code together. It looks back through the timeline to find the last photo where both branches were the same (the common ancestor).
It then looks at the current main photo, the current feature-A photo, and the ancestor. It says: "Since the ancestor, main changed line 5 and feature-A changed line 10. I can combine those easily."
5. The "Undo" Mindset
In Git, you rarely "delete" history; you just move your feet to a different spot on the timeline.
Checkout means "Show me this old photo."
Reset means "Move my sticky note back to an older photo."
Revert means "Make a new photo that looks exactly like an old one."
Conclusion: Beyond the Magic Spells
Gaining an understanding of the .git folder turns Git from a set of "magic spells" that you must commit to memory into a clear, logical system. As we've seen, Git manages a complex database of Blobs, Trees, and Commits in addition to saving changes. Git guarantees that the history of your project is unchangeable and impervious to corruption by employing SHA-1 hashes. Every piece of information has a distinct fingerprint in this system, and each iteration of your project is merely a snapshot in a lengthy, safe chain of trust.
See the "plumbing" taking place beneath the surface the next time you run git add or git commit: the content is being hashed into Blobs, the directory structure is being mapped into Trees, and a new Commit is extending the timeline. You can more confidently explore, experiment, and "time travel" through your code when you stop memorising commands and start thinking in Snapshots and Pointers.
The.git folder is the memory of your project, not a black box. When you become proficient with the memory, you become proficient with the tool.
