How Git works

This chapter follows A short history of Git.

Most IDEs expose Git through buttons and menus. Learning the model still pays off: when a merge fails or a reset looks scary, you need to know which area of the repository a command touches and whether it creates new commits or only moves pointers.

What version control is solving

Software changes in parallel: features, fixes, experiments, releases. Without version control you copy folders, email zips, or overwrite each other’s files. A VCS records who changed what, when, and why, lets you compare versions, revert mistakes, and merge work from multiple people.

Centralized systems (classic Subversion) store one canonical history on a server; clients check out snapshots and send commits upstream. Distributed systems (Git, Mercurial) give every clone a full history. You commit locally, then exchange commits with remotes. Git chose distribution and snapshot-based storage over delta-only central storage.

Snapshots instead of file-by-file diffs

Many tutorials describe Git as storing diffs. At the object level Git stores snapshots: each commit points at a tree of file contents (via blobs). Unchanged files often reuse the same blob across commits, so storage stays efficient without treating history as one long patch series.

The basic workflow

You either git init an empty repository or git clone an existing remote. You work on a branch (often main by default). Each teammate with a clone has an independent copy of the full history.

Changes start untracked in the working tree. git add stages them in the index (staging area). git commit writes a new snapshot to the local repository and moves the branch pointer forward. git push sends commits to a remote; git fetch downloads commits you do not have yet without necessarily merging them into your branch.

Four areas

Every Git command moves data between these areas or updates refs in the repository:

When you run a command, ask:

1. How does this move content across the four areas?
2. Does it create new objects, or only move branch/tag refs?

flowchart LR
  WT[Working tree]
  IDX[Index]
  REPO[Repository]
  WT -->|"git add"| IDX
  IDX -->|"git commit"| REPO
  REPO -->|"git checkout / restore"| WT
  REPO -->|"git checkout / restore"| IDX

The .git directory and object store

A Git project is a directory plus a hidden .git folder (created by init or clone). Inside objects/ Git stores blobs (file contents), trees (directory listings pointing at blobs and subtrees), and commits (metadata, parent pointer(s), root tree).

gitGraph
  commit id: "c1"
  commit id: "c2"
  branch feature
  checkout feature
  commit id: "c3"
  checkout main
  commit id: "c4"
  merge feature id: "m1"

Each commit is a node in a directed acyclic graph. A commit knows its parent (two parents for a merge commit). A branch is a movable name pointing at a commit. HEAD usually points at your current branch, which points at a commit.

Deleting a branch name does not instantly delete commits: it removes a pointer. Commits that become unreachable are eventually removed by garbage collection (git gc).

Shared objects and renaming

Blobs and trees are deduplicated by hash. If two commits contain the same file bytes, they share one blob. Renaming with mv and staging both paths often shows up as a rename in git status because Git detects similar content, even though internally it still stores blobs and trees.

Removing a file from the index but keeping it on disk uses git rm --cached. A plain git rm removes the file from the working tree and stages the deletion.

Why the model matters before commands

Commands in the next chapters are easier to remember once the areas and objects are familiar:

• git reset moves a branch and optionally resets index and working tree.
• git merge and git rebase combine histories differently while reusing the same object store (Merging versus rebasing).
• git cherry-pick copies a commit’s changes onto another branch.

Next: Everyday Git commands.