How Git works

Why use version control?

Imagine you are playing a video game where you can save your progress at any point. If you die in the game, you need to reload your last save. How much progress you lose depends on how recently you last saved.

If you mess up your last save (like saving in a situation where you are doomed to die every time), you will be glad to have access to your previous saves as well.

Git keeps versions of files so that we can retrieve them later, even if just to make sure we don't lose too much progress if something goes wrong. Who hasn't had a "Presentation_v5_final.pptx" on their USB drive at some point? We can also use it to share those files with our colleagues, compare them with older versions, and more.

Snapshots

Each time we want to save our "game," i.e., the progress in our text or source code files, Git creates a new version of the project in a database called the repository. These versions are usually referred to as revisions or commits (named after the process of committing the current version to the repository).

There's a common misconception that commits represent just the changes since the previous version, but although Git uses some tricks to avoid storing unchanged files redundantly, each commit still references all relevant files and conceptually it's a snapshot of the whole project.