Summary: Why git exists

The problem

Files evolve over time. People collaborate on the same files. Mistakes happen and need to be undone. Without a system for tracking these realities, work gets lost, history disappears, and collaboration breaks. Ad-hoc approaches (file naming conventions, manual backups, thumb drive copies) fail at scale.

What version control adds

A complete record of how a project evolved, recoverable at any point. That record is itself a useful artifact. It answers questions about what the project looked like in the past, who changed what, and lets you restore earlier states with confidence.

The mental model that matters

Git stores snapshots of project state over time. Every commit is a complete picture of every file in the project at that moment. The sequence of commits forms a recoverable history.

This snapshot model is the foundation for every other git command. Commit makes a snapshot. Checkout loads a snapshot. Diff compares two snapshots. Branch starts a parallel sequence. Merge combines parallel sequences.

Distributed vs centralized in one sentence each

Centralized: one server holds the canonical history; clients connect to it for every operation that touches history.

Distributed: every clone holds the full project history; operations are local; sharing happens by pushing to other clones, none of which are architecturally privileged.

Three signs a project needs version control

1. More than one person edits the project
2. The project evolves over time and earlier versions might matter
3. The consequences of a mistake are non-trivial

What you carry into L2

The snapshot model, plus the disposition that version control is collaboration infrastructure. L2 makes the snapshots real with actual commands.

Remember this if nothing else

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