Whilst watching a tutorial on Lynda.com regarding Distributed Version Control Systems vs Centralized Version Control Systems, I came across some text which confused me on how Git tracks differently than the Centralized Version Control Systems. I always thought the mentioned VCS were tracking changes and when commiting you are saving the snapshot of these changes to the repository which is used to get from version-to-version. But for some reason the following text claims that Git doesn't work this way.
Can anyone try to explain and clearify this for me?
In Git the changes are stored as change sets or patches, and we're focused on tracking changes not the versions of the document. Now that's a subtle difference, you may think, well, CVS and SVN those track changes too, they don't. They track the changes that it takes to get from version-to-version of each of the different files or the different states of a directory. Git doesn't work that way, Git really focuses on these change sets in encapsulating a change set as a discrete unit and then those change sets can be exchanged between repositories. We're not trying to keep up-to-date with the latest version of something instead the question is, do we have a change set applied or not?
This tutorial is terribly wrong:
Here is what I have to say about distributed vs centralized in my own book:
The key difference between these two kinds of systems is that a centralized VCS has a designated master repository. There may be multiple copies of the master, or even multiple masters with some kind of synchronization protocol (e.g., ClearCase MultiSite), but there is only one master. Their design assumes this single-master-ship and thus is allowed to depend on it.
With a distributed VCS, there is no designated master repository. Users generally have a complete, private copy of each repository. Communications between these private copies are, at least in principle, peer-to-peer operations: neither repository is any more masterful, and conflicts—situations where both Alice and Bob have made changes to the same regions of the same files—can and do occur and require some kind of resolution.
It’s always possible to use a distributed VCS in a centralized manner: you simply designate one particular repository as the master version, and coordinate updates to it. However, centralized systems often provide features like locking source files or directories, restricting access (for read and/or write, to particular files, directories, and/or branches), and so on. With a typical DVCS it’s more difficult (though not technically impossible) to provide these, and Git and Mercurial simply don’t, at least not without add-ons. With CVCSes that provide locking, users may lock files (typically just one specific version ID) to prevent other users from making conflicting changes. This is conceptually easier, but of course it can prohibit parallel work.