Version control is the practice of recording changes to files over time so a project’s history can be inspected and earlier states recovered. Early widely used systems such as CVS and Subversion were centralized: a single server held the one authoritative repository, and each developer kept only a working copy of the latest files. To see history or commit a change, the developer had to contact that central server.
Distributed version control takes a different shape. Every clone is itself a complete repository, carrying the full history of the project rather than just the current files. Mercurial, one of the best-known examples, describes itself plainly as “a free, distributed source control management tool.” Git, which appeared in 2005, follows the same model.
The practical consequences are significant. Because the whole history lives locally, operations like viewing the log, creating branches, and committing run without a network round-trip, which makes them fast. There is no single point of failure: if a server is lost, any full clone can restore the project. And there is no privileged central copy by design; teams choose by convention which repository they treat as the shared one.
This model reshaped collaboration. With every participant holding a complete, independent copy, people can work offline, experiment on cheap local branches, and exchange changes directly with one another. That flexibility is part of why distributed tools, and git in particular, displaced the earlier centralized systems for most new projects.