Understanding Git Internals

We use Git every day - git add, git commit, git push - but have you ever wondered what actually happens when you run these commands? Let's peek under the hood and understand how Git really works.

The .git Folder: Git's Brain

When you run git init, Git creates a .git folder in your project. This folder is Git's entire brain - it contains everything Git knows about your project's history.

Here's what's inside:

.git/
├── HEAD              # Points to the current branch
├── config            # Repository-specific configuration
├── description       # Repository description (used by GitWeb)
├── hooks/            # Client and server-side hook scripts
├── info/             # Global exclude file for ignored patterns
├── objects/          # Git's object database (the most important!)
│   ├── pack/         # Compressed object storage
│   └── [hash dirs]   # Individual object files
├── refs/             # References to commits (branches, tags)
│   ├── heads/        # Local branches
│   ├── remotes/      # Remote branches
│   └── tags/         # Tags
└── index             # The staging area (more on this later)

The key insight: Your working directory is just a checkout. The real project history lives in .git/objects.

Git Objects: The Building Blocks

Git stores everything as objects, and there are three main types:

1. Blob (Binary Large Object)

• Stores file content

• Just the content, no filename or metadata

• Identified by a SHA-1 hash of the content

2. Tree

• Like a directory listing

• Maps filenames to blobs or other trees

• Represents the structure of your project at a point in time

3. Commit

• Points to a tree (snapshot of your project)

• Contains metadata: author, message, timestamp

• Points to parent commit(s), forming the history chain

What Happens During git add?

When you run git add file.txt:

1. Git calculates a hash of the file content (SHA-1)

2. Compresses the content and stores it as a blob in .git/objects/

3. Updates the index (staging area) to point to this blob

Important: The file content is already saved in Git's database, even before you commit!

What Happens During git commit?

When you run git commit -m "message":

1. Git creates a tree object representing your staged files

2. Git creates a commit object that:

   • Points to this tree

   • Contains your commit message

   • Points to the parent commit (previous commit)

   • Stores author info and timestamp

3. Updates the branch pointer (e.g., refs/heads/main) to point to this new commit

How Git Uses Hashes

Every Git object has a unique SHA-1 hash (40 characters, like a3b2c1d4e5...). This hash is:

• Content-based: Same content = same hash

• Used as filename: Objects are stored as .git/objects/ab/c123...

• A guarantee of integrity: If content changes, hash changes

This is why Git can detect if files have changed - it just compares hashes!

The Mental Model

Think of Git like this:

• Blobs = Pages of a book (content only)

• Trees = Table of contents (structure)

• Commits = Bookmarks with notes (snapshots + history)

• Branches = Sticky notes pointing to bookmarks

When you make changes:

1. git add → Save pages (blobs) and update the draft table of contents (index)

2. git commit → Create a new bookmark (commit) with a finalized table of contents (tree)

Key Takeaways

1. The .git folder is Git's database - everything is stored there

2. Git stores snapshots (commits), not differences

3. Objects (blob, tree, commit) are the core data structures

4. Hashes ensure data integrity and enable Git's superpowers

5. Branches are just lightweight pointers to commits

Understanding these internals helps you reason about Git commands instead of memorizing them. Next time you run git add, you'll know you're creating a blob and updating the index. When you git commit, you're creating a tree and a commit object that preserves a snapshot forever.

Happy versioning!