Most version control systems store changes as a set of differences, or deltas. If you change a line in a file, the system records just that change. Git doesn't work this way. Instead, every time you commit, Git essentially takes a picture of all your files at that moment and stores a reference to that snapshot. If a file hasn't changed, Git doesn't store the file again; it just includes a link to the previous identical version it has already stored. This approach makes operations like branching and checking out past versions incredibly fast.

This design choice makes Git fundamentally a content-addressable filesystem. In systems you might be familiar with, like RAG pipelines, you retrieve information based on a query. In Git, you retrieve data based on its content. Every piece of content, from a single file change to an entire project snapshot, is run through a hashing algorithm and given a unique ID. This ID, a SHA-1 hash, is derived directly from the content itself. If the content changes, even by a single bit, the hash changes completely. This ensures the integrity of your data; it's impossible to change a file's history without Git knowing about it.

Everything in Git is stored as one of three types of objects: blobs, trees, and commits. These are all kept inside the .git/objects directory, a simple key-value data store where the key is the object's SHA-1 hash and the value is the compressed object data.

Let's break down the three fundamental objects that make up Git's database.

Next, there are tree objects. A tree is like a directory. It stores a list of blobs and other trees, essentially mapping filenames to their corresponding content (blobs) or subdirectories (other trees). Each entry in a tree contains a pointer (the SHA-1 hash) to a blob or another tree, along with the file's mode, type, and name. This is how Git reconstructs the file hierarchy for any given snapshot.

Finally, the commit object ties everything together. It contains a pointer to the single top-level tree that represents the project's root directory for that snapshot. It also includes metadata: the author and committer information, a timestamp, and a log message. Crucially, it also contains a pointer to one or more parent commits, which is what creates the historical chain of changes. A commit with one parent is a regular commit, while a commit with multiple parents is a merge commit.

You can inspect these objects yourself using a few plumbing commands. For example, to see the contents of an object, you can use git cat-file -p <SHA-1_hash>.

Understanding this object model is the key to mastering Git. When you run commands, you're not just manipulating files; you're creating and navigating a graph of these interconnected objects. This structure is what gives Git its power and flexibility.

Let's test your understanding of Git's core concepts.

Now that you understand how Git stores its data, you can start to appreciate why commands for branching, merging, and reviewing history work the way they do.