Trees (The Directories)
If Blobs are the files, Trees are the folders. But like everything else in Git, a Tree is just a simple text file under the hood.
Connecting Names to Hashes
Because Blobs don't know their own filenames, Git uses **Tree Objects** to organize them. A Tree object is literally just a list mapping a human-readable filename (like `index.js`) to a cryptographic Blob Hash (like `b2e6...`).
Working Directory (What you see)
The Tree Object
A Tree is basically a directory file. It maps human-readable filenames to the raw cryptographic Blobs.
The Blob Objects
Blobs strip away filenames. If you have 5,000 files with the exact same content, Git only stores ONE blob.
Reading the Tree
Look at the **Tree Object** in the simulation above. It looks exactly like output from an old UNIX terminal: 100644 blob [hash] index.js.
Hover over any row in the Tree Object list. You'll see exactly which Blob it points to in the database! Notice how both `index.js` and `utils.js` point down to the exact same Blob Hash. This Tree file acts as the blueprint to reconstruct your project directory.
Trees can point to Trees!
What happens if you have a folder inside a folder? Git creates a Tree object that points to another Tree object hash. Its type changes from `blob` to `tree`. This hierarchical nesting is exactly how the 'Merkle Tree' is built.
Seeing a real Tree
If you run ls-tree on any tree hash, or even just passing a branch name like `main` (which resolves to a commit, which resolves to a tree), you can see this exact table natively!