Git does include for each commit a full copy of all the files, except that, for the content already present in the Git repo, the snapshot will simply point to said content rather than duplicate it.
That also means that several files with the same content are stored only once.
So a snapshot is basically a commit, referring to the content of a directory structure.
Some good references are:
You tell Git you want to save a snapshot of your project with the git commit command and it basically records a manifest of what all of the files in your project look like at that point
- 2020: “A commit in Git: Is it a snapshot/state/image or is it a change/diff/patch/delta?“
- git immersion
Lab 12 illustrates how to get previous snapshots
The progit book has the more comprehensive description of a snapshot:
The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data.
Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time
Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem.
Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored.
Git thinks about its data more like as below:
This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS.
See also:
- “If git functions off of snapshots of files, why doesn’t
.git/become huge over time?“ - “What information is stored as each git commit’s tree object content“
Jan Hudec adds this important comment:
While that’s true and important on the conceptual level, it is NOT true at the storage level.
Git does use deltas for storage.
Not only that, but it’s more efficient in it than any other system. Because it does not keep per-file history, when it wants to do delta compression, it takes each blob, selects some blobs that are likely to be similar (using heuristics that includes the closest approximation of previous version and some others), tries to generate the deltas and picks the smallest one. This way it can (often, depends on the heuristics) take advantage of other similar files or older versions that are more similar than the previous. The “pack window” parameter allows trading performance for delta compression quality. The default (10) generally gives decent results, but when space is limited or to speed up network transfers,git gc --aggressiveuses value 250, which makes it run very slow, but provide extra compression for history data.