Git如何解析树对象内容？如何随时访问各类对象指针？

Great question—let's unpack how Git handles tree objects and navigates its entire object graph. Git's object model is all about lightweight, hash-addressed objects, so once you understand the basics, the rest falls into place.

What a Tree Object Actually Contains #

First, let's clarify: a tree object isn't a file itself—it's a directory listing that points to other objects (either blobs for files, or other trees for subdirectories). Each tree object is stored in Git's object database (./git/objects) as a compressed, hash-addressed file.

If you want to see what a tree object looks like in plaintext, run this command on any tree hash (you can get one from a commit with git rev-parse HEAD^{tree}):

git cat-file -p <tree-hash>

You'll see output that looks something like this:

100644 blob a1b2c3d...   README.md
040000 tree e4f5g6h...   src
100755 blob i7j8k9l...   script.sh

Each line breaks down into three parts:

• File mode: Permissions (e.g., 100644 for regular files, 040000 for directories/trees, 100755 for executable files)
• Object type & hash: Either blob (file content) or tree (subdirectory), followed by the 40-character SHA-1 hash of that object
• Filename: The name of the file or subdirectory

How Git Parses a Tree Object #

When Git needs to read a tree object, here's the step-by-step process:

1. Locate the object: Git uses the SHA-1 hash to find the compressed file in ./git/objects (the hash is split into two parts—first two characters are the directory, next 38 are the filename).
2. Decompress it: All Git objects are compressed with zlib, so Git first unzips the file to get the raw content.
3. Parse the raw structure: The raw tree content is a binary format where each entry is structured like:

   [file-mode] [filename]\0[20-byte binary hash]
   

   The null character (\0) is the key separator here—Git uses it to split the filename from the binary hash (since filenames can have spaces, a space separator wouldn't work).
4. Convert to human-readable format: Tools like git cat-file or git ls-tree take that parsed data and format it into the readable list we saw earlier.

Extracting File Content from Tree Objects #

Remember: tree objects only point to content—they don't store it. To get the actual file content:

1. Get the blob hash: From the tree object, grab the SHA-1 hash of the blob associated with the file you want.
2. Retrieve the blob object: Git fetches that blob from the object database, decompresses it, and the raw content of the blob is exactly the content of the original file.

For example, to read the content of README.md from the tree above:

git cat-file -p a1b2c3d...

This will spit out the exact text of the README file.

How Git Accesses Trees, Commits, and Blobs Efficiently #

Git needs to quickly jump between commits, trees, and blobs—here's how it does it:

• Hash-based direct access: Every object is uniquely identified by its SHA-1 hash. Git can instantly look up any object by its hash in the object database (or in pack files, more on that below).
• References (refs): Branches, tags, and HEAD are just pointers to commit hashes. For example, ./git/refs/heads/main contains the hash of the latest commit on the main branch. That commit object then points to a root tree, which points to subtrees and blobs.
• Index file: The ./git/index file acts as a cache for the current working tree's state. It stores pointers to the latest blobs and trees, so Git doesn't have to re-parse the entire directory structure every time you run commands like git status.
• Pack files: As your repo grows, Git compresses multiple objects into single "pack files" (./git/objects/pack/) to save space. Each pack file has an index that maps object hashes to their position in the pack, so Git can quickly find and extract individual objects without unpacking the whole file.
• Object caching: Git keeps recently accessed objects in memory (and sometimes on disk in a loose format) to speed up repeated access.

内容的提问来源于stack exchange，提问作者Mano Sriram