Git Repository Size Calculator

A Git repository stores every version of every file as content-addressed objects under .git/objects, keyed by a hash of their contents. Four object types exist: blobs holding file contents, trees describing directory listings, commits pointing at a tree plus parents and authorship metadata, and tags. Identical content is stored exactly once no matter how many commits or branches reference it, which is why branches are nearly free: a branch ref is a small file containing a single 40-character hash. Growth therefore comes from genuinely new blob content over time. Git first writes objects loosely, each zlib-compressed on its own, then repacks them into pack files where similar objects are stored as deltas against a chosen base. For source code, where each revision differs from the last by a handful of lines, delta plus zlib commonly reduces stored history to roughly 10 to 30 percent of its naive size, which is the compression assumption behind this estimate. Binary assets break that assumption: a re-exported PNG or a recompiled executable usually differs across most of its bytes, so each revision costs close to full size. Useful thresholds: GitHub advises keeping repositories under 1 GB, warns above 5 GB, and rejects individual files over 100 MB. Any estimate here is an approximation, since real delta efficiency depends on file types, commit granularity, and how recently garbage collection ran. Only git count-objects -vH reports the true figure.

Git was written by Linus Torvalds in April 2005 after BitMover withdrew the free license for BitKeeper, the proprietary system the Linux kernel had used since 2002. The first commit landed on 7 April 2005, the kernel tree was being managed with it within weeks, and Junio Hamano became maintainer in July 2005, a role he has held ever since. The design priorities were speed, fully distributed operation, and strong integrity guarantees, which led directly to a content-addressed object store rather than the per-file revision model used by CVS and Subversion. The original implementation wrote only loose objects, which was simple but wasteful. Pack files with delta compression were added within the first year to make cloning the kernel history practical over a network, and git gc later automated repacking once loose objects accumulate past a default threshold of about 6,700. Shallow clones, sparse checkout, and partial clone filters followed over subsequent years to keep large histories workable in continuous integration. GitHub released Git Large File Storage in April 2015 to address the binary asset problem, replacing large files with small pointer files backed by a separate server. History-rewriting tools answered the same need: the BFG Repo-Cleaner and, later, git-filter-repo by Elijah Newren, which superseded the notoriously slow built-in git filter-branch.