Marcio Cunha

How Git Internally Organizes Commit, Tree, and Blob Objects Inside the Dot Git Folder

Discover how Git stores your code history through an elegant structure based on immutable files called blobs, trees, and commits. Understand the inner workings of the dot git folder without mysteries.

Marcio Cunha5 min
Also available in:EspañolPortuguês
Summary
  • The Git version control system treats all code as a content-addressable database powered by cryptographic hashes.
  • Individual files are saved as blobs containing only raw data without filename or permission metadata.
  • Folders and directories are represented by tree objects that map filenames to their respective blob hashes.
  • Every saved change generates a commit pointing to a main tree while storing authorship history and messages.
  • The hidden folder residing at the project root concentrates all this data efficiently and deduplicated.

Behind the Scenes of Version Control

When we type simple commands like adding files to staging or saving history in the terminal, we rarely stop to think about what happens behind the scenes. In practice, Git operates as a highly optimized database focused on integrity, running entirely locally before any synchronization with remote servers. All this clever engineering is stored in a special hidden folder at the root of any versioned project, acting as the brain and persistent memory of the tool.

Instead of storing complex text diffs like older systems did, Git prefers taking complete and intelligent snapshots of the project state. To achieve this without consuming gigabytes of disk space on your computer, it breaks content into atomic pieces and reuses everything that remains identical. Understanding this internal architecture completely changes how you view everyday commands, turning once-mysterious operations into perfectly predictable logical flows.

The Core Concept of Content Addressing

The backbone of all Git inner workings is a mathematical function called a cryptographic hash, specifically the SHA-1 algorithm. In practice, think of this function as a digital meat grinder: you feed any volume of text or file into it, and it returns a unique sequence of forty alphanumeric characters. If you change even a single comma in the original file, the generated result will be completely different, ensuring absolute unambiguous identification.

This mechanism is technically known as content-addressable storage. This means the original filename matters very little to the system, as the data identity is defined strictly by its raw content processed through the hash. As a direct consequence of this design choice, if two identical files exist in different folders of your project, Git will store only a single physical copy on disk, saving precious resources and ensuring impressive execution speed.

The Role of Blobs in Storing Raw Data

The smallest brick of this architectural construction is the object called a blob, short for binary large object. In practice, a blob is simply the raw content of a file, stripped of any metadata such as filename, creation date, or access permissions. If you create a text file containing only the opening sentence of a book, the generated blob will strictly contain those characters, nothing more.

Because blobs do not store the filename, they must be referenced by other structural mechanisms to make sense within a working directory context. This separation between actual content and naming metadata is the secret that allows Git to rename files instantly without rewriting large blocks of data on the hard drive. The system simply updates pointer references, keeping the original blob intact and untouched at its immutable address.

The Organizational Structure of Tree Objects

If blobs only hold the filling of files, tree objects act as the skeleton that organizes those files into folders and subdirectories. In practice, a tree functions as a virtual directory that lists filenames, access permissions, and the hash codes corresponding to blobs or other sub-trees contained within it.

This directory tree creates a hierarchy identical to the folder structure you see on your operating system. When you navigate through a versioned project, Git reads these chained trees to dynamically rebuild the directory tree on your screen. Thus, a single root tree in the project can point to multiple sub-trees and blobs, forming a complex yet perfectly traceable and organized web of data.

The Commit Object as a Temporal and Authorial Milestone

While blobs hold data and trees organize folders, the commit object is responsible for tying all of this to a human and temporal context. In practice, a commit contains a pointer to the main tree representing the project at that exact instant, along with crucial metadata such as the author name, email, modification date, and explanatory message typed in the terminal.

Beyond this authorship information, a commit also stores the hashes of its direct predecessors, forming an unbreakable chain of history called a directed acyclic graph. It is this chained structure that allows Git to travel back in time, compare older versions, or point to parallel development branches without losing track. Each successful save adds a new indestructible link to this chain of events.

Inside the Dot Git Folder Anatomy

All of this sophisticated engineering is stored inside the hidden folder at the root of your working repository. Opening this directory in your file explorer reveals a series of strategic subfolders, the most important being the objects folder, which physically houses all blobs, trees, and commits generated over time.

To optimize space and avoid thousands of loose files in the operating system, Git compresses these objects using the standard zlib format and distributes them into subfolders whose names come from the first two characters of the hash code. The rest of the hash serves as the name of the compressed file inside. This smart organization prevents file system performance bottlenecks even when dealing with giant projects containing hundreds of thousands of files.

Final Considerations on Git Architecture

Understanding how Git internally organizes its objects reveals that its robustness comes not from magic tricks, but from well-applied fundamental computer science principles. Data immutability combined with content addressing creates an environment incredibly secure against file corruption and accidental history loss. This transparent architecture ensures any developer can audit, fix, or simply understand the exact state of their repository by directly examining the raw files stored on the machine.

Ultimately, mastering these internal concepts elevates your ability to resolve complex conflicts, revert disasters in the terminal, and use the system with total confidence. Git stops being a black box full of memorized commands and becomes a predictable, logical tool whose structural elegance continues to fascinate software engineers worldwide.