How big is a Git commit?

A practical exploration of how much space a Git commit consumes, showing that commit size varies with file compressibility, repository tree size, and whether objects are packed. Git stores objects as zlib-compressed loose objects and later repacks them into packfiles that eliminate redundancy across objects, so raw sizes depend on repetition in files and on whether packfiles exist. The write-up explains that even tiny changes can incur kilobytes of overhead because Git stores object metadata and snapshots of trees, and that larger commits often store a fraction of the uncompressed data due to compression.

A set of hands-on experiments (all using loose objects, no packfiles) reports concrete results: an empty .git is about 64,828 bytes; committing 250 tiny files added 47,640 bytes (total ~112,468); changing 3 bytes in a 50-file tree added 17,145 bytes; changing 3 bytes in a single-file repo added 8,709 bytes. Adding a 583,840-byte binary increased .git by 297,873 bytes, while committing a 16,415,223-byte source file added 1,622,188 bytes. The takeaway is that Git is very space-efficient: small commits carry kilobytes of overhead, and larger files are typically stored at roughly 50%-10% of their uncompressed size, with packfiles able to reduce storage further.