Tasty Git | 2nd bite | Snapshots

A series of bite-size articles about the version control system known as Git!

Snapshots

In the last article, I mentioned that version control systems tend to optimize for storage by storing differences between files rather than entirely new copies when a new version needs to be stored. We call this approach to version control delta-based.

The truth is that Git is an exception, and this is an important concept to grasp.

When you start using Git, you inform it where your project is and which files it should keep tabs on for you.

When you’ve made changes to one or more of those files, you can choose a moment to save those changes. We call this process committing, or making a commit.

And when you finally commit, Git will store the state of all of the files it is tracking for you as a version of your project. We refer to this as a snapshot. That means that conceptually, Git is not storing differences between files and it’s not even storing the state of just the changed files. Instead, when you commit, Git stores the whole of all your files in a snapshot that records what they all look like at that moment.

It then keeps a unique reference to that snapshot so you can revert the state of your files back to that moment at a later time, or check which changes were made since a snapshot was taken. You can think of this as the unique name of the snapshot.

Of course, storing copies of all your project files every time you made a commit would be incredibly inefficient. It would take a lot of work and a lot of storage space. So for files that haven’t changed, snapshots simply reference the existing unchanged copies of prior snapshots rather than storing a whole new copy. Only when a file is changed will a commit result in a new copy of that file getting stored in the snapshot.

Still hungry? Take the next bite →