How Git thinks: Git and code review

The handful of ideas that every Git command is built on. Learn these once and the commands stop feeling like magic spells.

Git is easier once you know that it works with three places and one repeated action: a change moves through them on purpose.

A change is edited in the working folder, picked into the staging area, then saved into the repository.

Think of packing a parcel. Your desk is covered with things (the working folder). You choose which items go in the box (the staging area). You seal the box, write a label on it and put it on the shelf (a commit in the repository).

Working folder

The ordinary folder on your computer where you edit files. Git watches it, but nothing is saved to history just because you changed a file.

Staging area

A waiting area for the changes you have chosen to include in your next save. Also called the index. It exists so that you can save one purpose at a time: you may have edited five files, but only two belong in this commit.

Repository

Your project plus its full history. Git keeps the history in a hidden folder named .git inside the project. You rarely open it. If you delete it, the project becomes an ordinary folder again.

Commit

One saved snapshot of the staged files, with a message you write, the author's name, the time, and a pointer to the commit before it. Because each commit points to its parent, commits form a chain, which is the history.

Every commit gets an ID, a 40-character fingerprint such as 29194b2a2352ce3ab3c991bf364679bf45b0378c. It is normally shown shortened to its first seven characters, 29194b2. You will copy these IDs, but you will never need to type all 40.

Branches and HEAD

Once there is a chain of commits, two more ideas complete the picture.

Branch

A movable label that points at one commit. Your main line of work is usually a branch called main. When you make a new commit on a branch, the label moves forward to it. Creating a branch only creates a new label, so it is instant and cheap.

HEAD

A "you are here" marker. It points to the branch you are on, and so to the commit you are working from. When you switch branches, HEAD moves.

Three commits and two branch labels. HEAD says you are working on shout. You will create exactly this in the next two parts.

For the curious Going deeper: snapshots, not differences

Many people assume Git stores each commit as a list of changes. It does not. Each commit records a snapshot of the whole project as it was at that moment. To save space, Git stores unchanged files only once and reuses them, and it compresses similar files together later (in pack files). When you ask for a diff, Git works it out by comparing two snapshots.

Inside .git, everything is an object named by a hash of its content: a blob holds a file's content, a tree holds a folder listing, and a commit points to a tree and to its parent commit(s). Because the name is derived from the content, changing anything in history changes every ID after it. That is why rewriting shared history is dangerous, and why a commit ID is a reliable fingerprint. Git can use SHA-256 for these hashes instead of the older SHA-1, but SHA-1 is still the default. Git's own documentation says SHA-256 is planned to become the default in Git 3.0, which has no release date yet.