How Git Works Internally

Most Git tutorials teach you what commands to run, but very few explain what Git is actually doing under the hood. That’s why Git often feels magical—or confusing—when things go wrong.

In this article, we’ll open the black box and explore:

• What the .git folder really is

• How Git stores data internally

• What blob, tree, and commit objects mean

• What actually happens during git add and git commit

• How Git uses hashes to guarantee integrity

The goal is simple: build a mental model of Git, so the commands finally make sense.

What Is Git Really?

At its core, Git is a system that records the history of your project.

It allows you to:

• Save versions of your code over time

• Go back to earlier states when something breaks

• Work with other developers without overwriting each other’s work

What makes Git different is how it stores this history.

Instead of tracking line-by-line changes in files, Git stores snapshots of your project.

• Each time you make a commit, Git saves what your project looks like at that moment

• If a file hasn’t changed, Git reuses the previous version

• If a file has changed, Git stores the new content

Git Stores All Its Knowledge in One Place

Everything Git knows about your project lives inside a hidden folder:

.git/

Understanding the .git Folder

When you run:

git init

Git creates a hidden .git directory.
This folder is the repository. If you delete it, Git forgets everything.

Why the .git Folder Exists

The .git folder stores:

• Your entire project history

• All commits, branches, and tags

• Metadata about configuration and references

Your working directory is just files.
Your .git directory is Git’s brain.

High-Level Structure of .git

.git/
├── objects/
├── refs/
│   ├── heads/
│   └── tags/
├── HEAD
├── index
├── config

Let’s break down the most important parts.

Git Objects: The Core of Everything

Inside .git/objects, Git stores four types of objects:

1. Blob – file contents

2. Tree – directory structure

3. Commit – snapshot + metadata

4. Tag – named references (optional)

You can think of Git as building history using Lego blocks.

---

4. Blob Objects: File Contents Only

A blob represents the contents of a file.

Key idea:

Git does not store filenames in blobs — only the raw content.

Example:

• hello.txt and greeting.txt with the same content → same blob

This is how Git saves space and avoids duplication.

---

5. Tree Objects: Directory Structure

A tree object represents a directory.

It contains:

• Filenames

• Permissions

• Pointers to blobs (files)

• Pointers to other trees (subdirectories)

Think of a tree as a folder snapshot.

tree
├── src/      → tree
│   └── app.js → blob
└── README.md → blob

Trees connect blobs together into a meaningful structure.

---

6. Commit Objects: Snapshots with History

A commit object ties everything together.

A commit contains:

• A pointer to a tree (project snapshot)

• A pointer to the parent commit(s)

• Author and committer info

• Commit message

• Timestamp

Important insight:

A commit does not store files — it stores a reference to a tree.

That’s why Git history is a graph, not a linear list.

---

7. What Happens During git add?

When you run:

git add file.txt

Git does three things:

1. Reads the file content

2. Creates a blob object (if it doesn’t already exist)

3. Stores a reference in the index (staging area)

The Staging Area (Index)

The staging area is a preview of the next commit.

It lives in:

.git/index

Think of it as:

“This is exactly what I want Git to remember next.”

---

9. What Happens During git commit?

When you run:

git commit -m "message"

Git:

1. Reads the staging area

2. Creates tree objects representing directories

3. Creates a commit object pointing to the root tree

4. Moves the current branch pointer to the new commit

No magic — just object creation and pointers.

---

10. How Git Uses Hashes for Integrity

Every Git object is identified by a SHA-1 (or SHA-256) hash.

That hash is computed from:

object type + size + content

This guarantees:

• If content changes → hash changes

• Objects cannot be silently corrupted

• History is tamper-evident

This is why Git is trusted for:

• Open-source projects

• Large distributed teams

• Long-term history

#chaicode #git