Skip to content

Cheatsheet: Why git exists

Git stores snapshots. Every other command is just navigating those snapshots.

This is the single sentence that makes every later git lesson coherent. Hold it.

TermDefinition
Version controlA system that records changes to a file or set of files over time so that any specific version can be recalled later.
CommitA saved snapshot of the entire project state at a specific moment, with a label and a timestamp.
SnapshotA complete picture of every file in the project at the moment a commit is made.
Centralized version controlAn architecture where one server holds the canonical project history; clients connect to it for history operations. Example: Subversion, CVS.
Distributed version controlAn architecture where every clone holds the full project history; operations are local; sharing happens by pushing between clones. Example: git, Mercurial.
CloneA complete copy of a project’s full history, made by a developer to a local machine.
RepositoryThe directory tree plus the git history that describes how the directory tree evolved.

Three signs a project needs version control

Section titled “Three signs a project needs version control”
  1. More than one person edits the project. Overwrites are inevitable without version control.
  2. The project evolves over time and earlier versions might matter. If you might want to recover an earlier state, version control is the system that lets you.
  3. The consequences of a mistake are non-trivial. When rollback matters, the cost of not having version control becomes asymmetric: small effort to set up, large pain to do without when needed.

Three reasons distributed beats centralized in practice

Section titled “Three reasons distributed beats centralized in practice”
  1. Offline work is possible because the full history is local
  2. Resilience against central-server data loss because every clone is a backup
  3. Cheap branching because branches are local and lightweight, not server-roundtripped

Treating git as a diff-tracking system rather than a snapshot system. Git does store diffs efficiently under the hood, but the conceptual model is snapshots. The snapshot model makes every later command coherent. The diff model leads to confusion when branching, merging, and rebasing show up later.

L2 makes the snapshot model real. It introduces:

  • git init to start tracking a project
  • git status to see what has changed
  • git add to stage changes for the next snapshot
  • git commit to take the snapshot
  • A .gitignore file to tell git what to ignore

L2 starts where L1 ends.