As I getting acquainted with Git, I feel more and more that:
Git and other DVCS jump a step futher than traditional centralized VCS in that they not only check out files in question, but also the whole version database.
I think this is the major difference between DVCS and CVCS, and also the major foothold of all other benefits of DVCS.
Or, let's put it this way:
Multiple Local VCS + A Centralized Backup = DVCS.
Changed the above equation to this:
Multiple Local Clones + A Centralized Backup = DVCS.
Right?
What you are describing is the very nature of a distributed system: the whole repository is cloned (with its full history).
a DVCS mixes version control (branching and labels) with publication (push/pull to/from remote repo)
But there are other characteristics that differentiate a DVCS from CVCS.
Especially in terms of workflow. See "Describe your workflow of using version control (VCS or DVCS)"
And don't forget that a DVCS doesn't have authorization or authentication. However, there are solutions to provide those, e.g. apache2-authn-redmine in combination with the Redmine Project Management System
The OP smwikipedia adds:
Multiple Local VCS + A Centralized Backup = DVCS.
I don't think you can summarize that way, especially considering it would be difficult to emulate the push/pull features since most of the VCS (SVN, ClearCase, Perforce, ...) have no "local" repo, only local working spaces, and depend heavily on their central repo.
If you really want to put it in one phrase, the main difference CVCS and DVCS for me is the fact, that everyone is working on their own versions, interchanging their updates (thus the distributed in DVCS). If you don't specifically tell git to, it won't download all branches from other contributors.
Check out gitworkflows for the idea behind it or the Bazaar Workflows for a very nice graphic repesentation of the possibilities (it is also possible to use git or any other DVCS like a CVCS).
That's one difference, yes. It allows to work off-line and propagate changes later.
Another difference, which can be seen as a consequence, is the branch management. When you work (and commit) locally, you create a new branch, by design. Changes propagation is simply branch merging. That's why git (and certainly hg and bzr) have strong merging algorithms.
(My first answer was simply, "yes." For once I'm glad of the 30-char limit.)
Except the centralized backup is completely optional. The "central" repo is a social distinction, not a technical one. You don't really check out "the one" version database. Rather, any given clone is the version database.
My one-line description is:
As many branches as you want, in as many repos as you want, sharing what, how, and with whom you want.
来源：https://stackoverflow.com/questions/7187191/one-word-to-summarize-git-and-other-dvcs