The Big Picture: What Git Really Is

At its core, Git is a content-addressable database.

That sounds fancy, but here’s the human version:

• Git doesn’t track files.

• Git tracks snapshots of content, and it names those snapshots using cryptographic hashes.

Understanding the .git Folder (Why It Exists)

When you run git init, Git creates a hidden directory. This folder is the repository. Your working directory is just a checkout of what’s stored inside .git.

If you delete .git, your project becomes a normal folder again.

What’s Inside?

Conceptually, the important parts are:

Git Objects:

Git only knows three object types. Once you understand these, Git clicks.

1. Blob — “Here is some content”

A blob (Binary Large Object) is the contents of a file.

• Nothing else.

• No filename.

• No permissions.

• Just raw bytes.

  Note: If two files have the exact same content even with different names—Git stores only one blob.

2. Tree — “Here’s a folder structure”

A tree maps filenames to blobs or other trees. It represents a directory.

3. Commit — “Here’s a snapshot + context”

A commit contains:

• A reference to one root tree.

• Author & timestamp.

• Commit message.

• Parent commit(s).

A commit does not store file contents directly. It just points to a tree, which points to blobs.

Visualizing the Relationship

Here is the entire Git data model in one view:

[ COMMIT e7d13b ]
      |
      +-- points to --> [ TREE (Root) ]
                             |
                             +-- "README.md" --> [ BLOB (content) ]
                             |
                             +-- "src/" -------> [ TREE (Folder) ]
                                                      |
                                                      +-- "app.js" --> [ BLOB (content) ]

How Git Tracks Changes

Git does not store diffs internally.

Instead, every commit is a complete snapshot.

• If a file hasn't changed, the new tree simply points to the existing blob.

• If a file has changed, the new tree points to a new blob.

So Git feels like it tracks changes—but internally it just links snapshots efficiently.

What Really Happens During git add

Let’s say you modify a file named hello.txt.

Step-by-Step Internally:

1. Git reads the file contents.

2. Git hashes the contents (SHA-1).

3. Git stores the content as a blob in .git/objects.

4. Git updates the index (staging area) to point to that blob.

What Really Happens During git commit

Now Git creates history.

Internally, Git:

1. Reads the staging area.

2. Builds tree objects from staged blobs.

3. Creates a commit object pointing to the root tree.

4. Stores the commit in .git/objects.

5. Moves the current branch pointer to the new commit.

That’s it. No files copied. No diffs saved. Just new objects and new pointers.

The Workflow Diagram

   WORKING DIR          STAGING AREA           .GIT REPO
 (Files on disk)          (Index)             (Database)
      |                      |                     |
      | -- git add  -------> |                     |
      |                      | -- git commit ----> |
      |                      |                     |
[Modified File]      [Pointer to Blob]    [Commit -> Tree -> Blob]

How Git Uses Hashes (Why Integrity Is Guaranteed)

Every Git object is named by a hash (e.g., e7d13b0f7c2d...). That hash is computed from the Object Type + Object Content.

Why This Matters:

• If content changes → hash changes.

• If a hash changes → every parent hash breaks.

This makes history tamper-evident. Git doesn’t ask “What changed?” Git asks “Do I already have this exact content?”

The Mental Model

If you remember only this:

Git is a graph of snapshots, not a list of changes.

Then the commands become descriptions of intent, not magic spells:

• git add = Stage content snapshots.

• git commit = Lock in a snapshot with metadata.

• Branches = Movable pointers.

• HEAD = Where you are right now.