Git Basics #1: What Git Is — the Snapshot Model and the Three Areas

Tools Git Version Control
7 min read

If you have ever managed code by copying files, you have probably created a folder like this: report_final.docx, report_final_real.docx, report_final_real2.docx. Sooner or later nobody can answer which file is actually the latest, what changed between two of them, or which one to open to get back to last week’s version. The same thing happens with code, and once you add the condition that several people edit the same files at the same time, the copy-based approach collapses completely.

A version control system is the tool that solves this problem. It records the history of changes, lets you return to any point in the past, and merges edits from multiple people safely. And the standard in this field today is, overwhelmingly, Git. If you want the big picture of what problem Git solves before touching any commands, IT Basics for Non-Developers #5: Git and Version Control is a code-free introduction. That post explains the concepts; this series is a hands-on introduction where you run the commands yourself in a terminal.

It runs in six parts.

  • #1 What Git is — the snapshot model and the three areas ← this post
  • #2 add, commit, status — what the staging area means
  • #3 Branching and merging — fast-forward and 3-way
  • #4 Remotes — clone, fetch, pull, push, and what origin really is
  • #5 Undoing changes — restore, reset, and revert
  • #6 GitHub and your first Pull Request

This post builds the two core models you need before memorizing any commands — snapshots and the three areas — and goes as far as creating your first repository with git init. Once these two models are in place, every command in the remaining five parts reads consistently as moving snapshots between the three areas.

Three problems version control solves #

Compared with the copy-based approach, a version control system solves three problems.

  • History — who changed what, when, and why is recorded per change. Instead of putting dates in file names, you query the record itself.
  • Recovery — you can return precisely to a specific point: yesterday afternoon, or right before the release.
  • Collaboration — several people edit the same project at the same time and merge their changes later. The accident where someone’s work disappears depending on who saved last is gone.

In this series, history and recovery appear as actual commands in #2 and #5, and collaboration in #4 and #6.

Git stores snapshots, not deltas #

Most version control systems before Git accumulated per-file deltas — the first edit to file A, the second edit, and so on. Only differences were recorded, and reconstructing the full state at a given point meant replaying the deltas from the beginning.

Git takes a different approach. Every commit stores a snapshot of the entire project at that moment. A single commit is a record that points to the exact content of every file at that point in time. Of course, Git does not store unchanged files again and again. An unchanged file is kept as a reference to the identical content already stored, so storage size does not become a problem.

A commit carries two more things besides the snapshot: a pointer to its parent commit and metadata such as the author, timestamp, and message. Because each commit points to its parent, the full history forms a chain.

Commits — a chain of snapshots and parent pointers 
[C1] ◀── [C2] ◀── [C3]
  │        │        │
snapshot  snapshot  snapshot
(entire   (entire   (entire
project)  project)  project)

Each commit points to its parent. Starting from C3 and
following the pointers reconstructs the full history.
Note
Why this model matters becomes clear in #3. A branch is nothing more than a pointer to a specific commit on this chain, so creating a branch in Git costs practically nothing. This is exactly where Git contrasts with delta-based systems, where branching was heavy and slow.

The whole repository lives on your computer #

Git is a distributed version control system. When you copy a repository, you do not just receive the latest files — the entire history from the first commit onward lands on your computer. That is why committing, browsing history, and comparing versions all work without a network. This distinguishes Git from centralized systems, where you had to connect to a server just to commit.

The name GitHub probably comes to mind here. GitHub is not Git itself — it is a hosting service that keeps a remote copy of your repository. The repository on your computer and the one on GitHub are equal copies, and the commands that keep them in sync are push and pull, covered in #4. The collaboration workflow on top of GitHub is covered in #6.

Checking the install and first-time setup #

First, check whether Git is installed.

Checking the install 
git --version
# git version 2.47.1

If no version is printed, you need to install it. On macOS use xcode-select --install or Homebrew with brew install git, on Windows use the Git for Windows installer, and on Linux use your distribution package manager (dnf install git, apt install git).

Once the install is confirmed, introduce yourself to Git. This only needs to be done once.

First-time setup — name, email, default branch 
git config --global user.name "Jane Doe"
git config --global user.email "jane@example.com"
git config --global init.defaultBranch main

user.name and user.email are recorded as author information on every commit you make from now on. It is a good idea to use the email you will later connect to your GitHub account. init.defaultBranch sets the default branch name of new repositories to main. Instead of master, which Git used as the default for a long time, main is the de facto standard today and is also the default on GitHub. To verify the settings, run git config --list.

git init — what the .git directory really is #

Now create your first repository. An empty directory is all you need.

Creating the first repository 
mkdir hello-git
cd hello-git
git init
# Initialized empty Git repository in /Users/jane/hello-git/.git/

The output message says exactly what happened. All git init did was create a hidden directory called .git inside the current directory. Every commit, every snapshot, and every setting you create from now on is stored inside this .git. Conversely, the moment you delete the .git directory, the project history is gone entirely and the folder becomes an ordinary folder again.

Keeping the project folder and .git separate in your head makes the three areas in the next section click naturally. The project folder where you create and edit files is your workspace, and .git is the archive.

Tip
You will never need to open and edit files inside .git directly. Exploring its internals is good study material, but modifications must always go through git commands.

The three areas — how a file becomes history #

This is where most people get stuck when first learning Git. In Git, a file is not recorded with a single save button — it passes through three areas, each with a different role.

The three areas and the two moves 
working directory        staging area          repository (.git)
─────────────────        ────────────          ─────────────────
where you create         the waiting list      where commits
and edit files           of changes for        (snapshots) are
                         the next commit       stored permanently

      │                       │
      └────── git add ───────▶│
                              └───── git commit ──────▶ new snapshot recorded
  • working directory — the project folder you see right now. Everything you do in an editor happens here.
  • staging area — the waiting list of changes to include in the next commit. git add places changes into this area.
  • repository — the .git directory. git commit takes what is on the staging area, creates a new snapshot, and records it here permanently.

Editing a file does not record it, and adding it with git add does not mean it is recorded yet either. Only after git commit does a new link get added to the snapshot chain. But why the extra add step in the middle? That question is the topic of the next post. The one-line preview: it lets you design what goes into each commit.

Wrapping up #

The heart of this post is two models.

  • Git stores snapshots, not deltas. A commit is a bundle of a full snapshot and a parent pointer, and history is a chain of commits.
  • A file is recorded by passing through the three areas: working directory, staging area, repository. git add and git commit perform the two moves.

On top of that, we finished the first-time setup with git config and created the first repository with git init. In the next post, “Git Basics #2: add, commit, status — What the Staging Area Means”, we will create real files in this hello-git repository and run add, commit, status, and diff by hand to see why the staging area exists.

X