Git Fundamentals and Branching

Targeted versions: Git 2.55 (released June 29 2026) — check yours with git --version and upgrade if you're on anything older than 2.34, since some steps below assume a reasonably modern Git. git switch and git restore (introduced in Git 2.23, no longer marked experimental) are used here instead of the older, dual-purpose git checkout for changing branches and restoring files — that's the current recommended split, though checkout still works identically if you've learned it from an older tutorial. Git 3.0 is in active development (targeting late 2026) and will change some defaults — SHA-256 object hashing and reftable ref storage — for brand-new repositories only; nothing in this project is affected, and existing repos keep working unchanged. Verified against git-scm.com and the Git project's release notes, July 2026.

Git doesn't store a running diff of changes the way some people assume — it stores a full snapshot of your project's files at every commit, and is smart enough to reuse unchanged file content between snapshots so this stays cheap. There are three areas you're always moving files between: the working directory (the files you're actually editing), the staging area (also called the index — a draft of what your next commit will contain), and the repository (the permanent, committed history stored in .git).

A commit is a snapshot plus metadata (author, message, timestamp, and a pointer to its parent commit(s)) — chain enough of these together and you get a directed graph of your project's history. A branch is nothing more than a movable, lightweight pointer to one commit in that graph. HEAD is a pointer to whichever branch (or commit) you currently have checked out. Once that mental model clicks — snapshots, not diffs; branches are pointers, not copies — most of what feels mysterious about Git stops being mysterious.