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

Every commit tells a story. Every hash preserves a moment. Understanding Git is not just about code—it’s about mastering the history of your work.

Introduction

We’ve all used Git to track changes, commit code, and collaborate with others.
But have you ever wondered what actually happens behind the scenes?

How does Git know what changed, how commits are connected, or how it keeps your history safe?

In this blog, we will peek inside Git and understand:

• The .git folder

• Git objects (Blob, Tree, Commit)

• How Git tracks changes internally

• How hashes maintain integrity

By the end, you’ll have a mental model of Git that goes beyond memorizing commands.

---

What is the .git Folder?

The .git folder is the brain of your Git repository.

When you run git init, Git creates this hidden folder in your project. It contains:

• The entire history of your project

• Metadata about commits, branches, and tags

• Objects that store your files and directories

Think of it like a database of everything your project ever was, stored efficiently and safely.

---

Git Objects: Blob, Tree, Commit

Git stores your project as a set of objects. Each object has a unique SHA-1 hash.
There are three main object types:

1. Blob

• Short for Binary Large Object

• Stores the contents of a file

• No file name or directory information

Example:

index.js -> blob SHA: abc123

2. Tree

• Stores directory structure

• Points to blobs (files) and other trees (subdirectories)

• Contains file names, permissions, and hashes

Example:

src/ -> tree SHA: def456
    - index.js -> blob SHA: abc123
    - utils.js -> blob SHA: 789xyz

3. Commit

• Points to a tree object

• Contains:

  • Author

  • Timestamp

  • Commit message

  • Parent commit(s)

• Forms a linked list of commits (history)

Example:

commit SHA: 112233
    tree: def456
    parent: 000000
    author: You
    message: "Initial commit"

---

How Git Tracks Changes

Git’s tracking flow:

1. Working Directory: where you modify files

2. Staging Area (Index): snapshot of changes ready for commit

3. Local Repository (.git): permanent storage of commits

Step 1: git add

• Copies file content into blob objects

• Updates the staging area (index)

• Prepares a snapshot for the next commit

Step 2: git commit

• Creates a tree object from staged files

• Creates a commit object pointing to this tree

• Links to parent commit

• Updates the branch reference

---

How Git Uses Hashes

Every object in Git has a unique SHA-1 hash (40-character string).

Why hashes?

1. Integrity: If the file changes, hash changes → Git detects it

2. Uniqueness: Each object is uniquely identified

3. History linking: Commits point to previous commits via hashes

Think of SHA-1 as Git’s fingerprint system.

---

Visual: Object Relationships

Here:

• C1 is initial commit

• C2 is next commit pointing back to C1

• Tree stores file structure

• Blobs store file contents

---

Building a Mental Model

When you do:

git add index.js
git commit -m "Add index.js"

Git internally:

1. Creates a blob object for index.js

2. Creates a tree object for the folder structure

3. Creates a commit object linking to the tree and parent commit

4. Updates the branch pointer (HEAD)

This happens in milliseconds, but now you know what’s under the hood.

---

Summary

• The .git folder is the heart of Git

• Git stores everything as objects: blobs, trees, commits

• git add → staging area → blob objects

• git commit → tree + commit objects

• SHA-1 hashes ensure integrity and uniqueness

• Mental model > memorizing commands

---

Next Steps

1. Explore .git/objects folder in a sample repository

2. Use git cat-file -p <hash> to inspect objects

3. Learn how branches, merges, and rebases manipulate commits

Understanding Git internally will make you a confident Git user, ready to debug errors, optimize workflow, and contribute safely to projects.