When a new Git repository is created with `git init`, the hidden `.git` directory already occupies about 64 KiB of disk space. This baseline reflects the internal folder structure, configuration files, and empty object database that Git sets up before any commits are recorded. Understanding this starting point is essential because every subsequent commit’s size is measured relative to this initial overhead.
The author’s experiments show where that overhead comes from. After creating a repository with 250 tiny files (each containing the word “foo”) and making an initial commit, the `.git` directory grew by roughly 47 KiB. Changing just three bytes in one of those files added about 17 KiB, while the same three‑byte edit in a repository that held only a single file increased the size by only 8.7 KiB. Each commit stores a commit object, one or two tree objects that list directory contents, and a blob object for the file’s new content—all compressed with zlib. The extra space for small edits is therefore dominated by the metadata objects rather than the actual data change.
For larger files the stored size grows much more slowly than the original file size. Committing a 583 KiB binary file added approximately 298 KiB, which is about 51 % of the file’s size, while a 16.4 MiB source file added roughly 1.6 MiB, or about 10 % of its size. This demonstrates Git’s compression effectiveness: the content is stored as zlib‑compressed blobs, and when many objects exist Git can pack them into packfiles that use delta compression to eliminate redundancy across similar files, potentially reducing storage even further.