Distributed version control systems were created to make collaboration possible without a central server, and thus overcome many of the common issues with CVCS. This can work based on a few core principles:
- Each collaborator has the full revision history
- Collaborators can branch and merge from each other easily
The result is an architecture where there is no technical center, and any participant can potentially be the center:
Instead of a central server with the complete revision history, each collaborator has the full history in his/her own personal branches. Although technically there is no need for a central server, typically there is a designated common "official" public branch aggregating the work of all collaborators:
In general, a DCVS can do everything that a CVCS can, and enable many additional features. One of the most interesting added features is the many possible workflows for exchanging revisions between collaborators, such as:
- Merging revisions peer-to-peer
- Centralized—a branch is designated as the "official" branch, which can be used by collaborators in exactly the same way as in centralized version control
- Centralized with gatekeepers—the "official" branch is accessible by designated maintainers of the project, who merge changes peer-to-peer and publish releases in the "official" branch
Distributed version control is especially suitable for large teams with physically disconnected collaborators, such as most open source projects. However, it can be just as useful at smaller scales too, even in a solo project.
Distributed version control has important implications in terms of keeping backups of the project. By design, it is very easy to replicate the full revision history on a remote location or even on a local backup disk, thus providing a simple and consistent backup method. Considering that every collaborator begins working on new revisions by first grabbing the full history of the project, the vast majority of the revision history is very difficult to lose; the full history can only get lost if all the collaborators lose all their work. On the other hand, since the changes of all the collaborators are not necessarily at a single central location but distributed across all their local environments, there is also no single place to back up all the work done in the project. Thus, it is up to each individual collaborator to make sure that their local changes don't get lost before they are merged into the official branch or into other collaborator branches. Fortunately, this is not difficult to achieve, and we will provide examples to demonstrate how you can enjoy the benefits of distributed version control and at the same time stay safe by replicating your new revisions at another location.