Why Version Control, and How Git Thinks

What version control is for

You already do version control by hand: budget-final.ods, budget-final-2.ods, budget-REALLY-final.ods. A version control system does it properly. It records each saved state of a set of files, with who saved it, when, and why, so you can ^{1 2}:

• see exactly what changed between any two versions,
• go back to any earlier state, of one file or the whole project,
• work on several things at once, then combine them,
• and share work with other people, or with your other computers, without overwriting each other.

It’s essential for software, and just as useful for scripts, configuration files, notes, and anything else made of text.

Git is the version control system nearly everyone uses. Linus Torvalds and the Linux kernel developers wrote it in 2005, after they lost free use of the commercial tool they’d been using ¹.

Snapshots, not differences

Many older systems stored a file’s history as a list of changes. Git thinks differently: each time you save, a commit, it records a snapshot of what every tracked file looks like at that moment ¹. If a file hasn’t changed, git doesn’t store it again; the new snapshot simply points to the copy it already has ¹.

Each snapshot also remembers its parent, the snapshot before it, so history is a chain of snapshots, and later a branching graph of them ².

Everything is local

A git repository holds the project’s entire history, and it lives right in your project folder, in a hidden subfolder named .git ¹. Looking at old versions, comparing them, making commits, and creating branches all happen on your own disk, so they’re instant and work offline ¹.

Services like GitHub host a copy of a repository so you can share it and back it up. But every copy, including yours, is a full repository; GitHub isn’t where git “lives” ¹.

Integrity

Everything git stores is checksummed and referred to by that checksum: a SHA-1 hash, 40 hexadecimal characters like 24b9da6552252987aa493b52f8696cd6d3b00373, computed from the contents ¹. Change one byte of one file and the hash changes, so git notices corruption, and history can’t be quietly altered. You’ll see these IDs everywhere; the first seven characters are usually enough to name a commit.

Once something is committed, it’s very hard to lose, especially if the repository is also copied somewhere else ¹. Uncommitted work is another story, which is a good reason to commit often.

Three states, three areas

The one thing Pro Git asks you to remember above all: a tracked file is always in one of three states ¹:

• Modified: you’ve changed it, but haven’t marked it to be saved.
• Staged: you’ve marked this version of it to go into the next commit.
• Committed: it’s safely stored in the repository.

Those states correspond to three areas ¹:

• the working directory, the files you see and edit;
• the staging area (also called the index), a list of what will go into the next commit;
• the repository, the .git folder, where commits live.

So the basic rhythm is: edit files, stage the changes you want with git add, and commit them with git commit. The staging area is what lets you commit just part of what you’ve changed, which you’ll use constantly. Lesson 3 does all of this for real.

Your turn

So

Version control records every saved state of a project. Git stores each commit as a snapshot of the whole project, sharing unchanged files, chained to its parent and named by a SHA-1 checksum. The full history lives in your project’s .git folder, and every file is modified, staged, or committed: working directory, staging area, repository.