Where does history live?
Local, centralized, and distributed systems differ in who holds the complete record and when a network is required.
Explore modelsA field guide to version control
Keep the change.
Keep the change.
Keep the context.
A clear map of how version control works: the models, the systems, the history behind them, and the commands worth remembering.
One project. Several lines of work. A history you can inspect.
The essentials
Three questions, five routes
Start with the idea, compare the tools, then find the exact operation you need.
Which system fits?
Compare Git, Mercurial, Subversion, and Fossil by workflow, storage, and collaboration model.
Compare systemsWhat do I type?
Short, task-oriented commands for inspection, branches, recovery, and sharing.
Browse commandsThe mental model
A version is more than a backup.
A version control system records related changes, identifies their authors, and lets a team compare, combine, and revisit states of a project.
A commit is a named point in that history. A branch gives work another path. A merge brings paths together. The repository preserves the relationship between them.
See how we got here$ git status --short M guide.md $ git diff -- guide.md # inspect the change before recording it $ git add guide.md $ git commit -m "Clarify the guide" # one documented step in project history
Tool architecture is not team policy.
Git is distributed even when a team agrees to merge through one central server. Subversion is centralized even when developers keep local working copies. The model describes where authoritative history and operations live; the workflow describes how people choose to collaborate.
Model
What the system permits
Full local history, server-based revisions, offline commits, and the shape of synchronization.
Read the model guideWorkflow
What the team agrees to do
Review rules, branch lifetimes, integration frequency, and release discipline.
See the trade-offs