After learning centralized version control systems, let us know more about the distributed version control system.
Unlike centralized VCS, where all the heavy lifting is done at the server side and acts as a single point for all the operations and the clients have only the working copy of the code-base; in distributed VCS, each client (referred as collaborator) has its own local repository and will work on its local repository for the most part.
1. How distributed version control systems work?
The whole approach of central VCS is reversed and each collaborator will have the complete repository on his local machine i.e. the complete revision history, all the branches, tags, commit information is present on the local machine. We do not have a notion of a central server, but we can configure any repository to be a central repository to treat as a source of truth and to integrate with build and deployment tools like Jenkins, Chef etc.
Below is the block diagram of how different collaborators work with a distributed version control system.
From the above diagram, we can see that, unlike traditional VCSs, in distributed VCS, we have collaborators who work with other collaborators in a decentralized system.
In distributed VCS, clients don’t just check out the latest snapshot of the files; rather they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data.
Also, note that the terminology used in distributed VCS differs from centralized VCS. Where we use “checkout” and “commit” in central VCS; in distributed VCS, we use “push” and “pull”.
- Push: Send a change to another repository (may require permission)
- Pull: Grab a change from a repository
There are many distributed version control systems like Git, Mercurial etc. In upcoming series of posts, I will be taking Git and will be referring to Git whenever referring to “distributed version control system”.
2. Advantages of distributed version control systems
Let us see the advantages of this approach over traditional/centralized version control systems.
Each collaborator checks out the codebase into his local repository and works on the local repository. Hence all the operations will be fast since there won’t be any network call to any server.
2.2. Cheap branching and merging
Since, the codebase is on the local hard disk, creating branches and merging is very simple and easy. This is one of the powerful features since working with branches and merging is too complicated if working with a centralized repository.
2.3. Local branching
The developer can create as many local branches and work on the branches and then merge them back to the main branch. Once the merging is complete, the local branch can be safely deleted. The biggest advantage here is that the branch will not be visible to others, unlike the centralized VCS where all the branches reside on one single server and creates a lot of confusion when working on a large project.
2.4. Snapshots instead of difference
This is one of the key benefits. We can get the complete code repository for each commit that we have performed. Hence we can easily revert back to any commit without having to deal with applying the changes from the base version manually as in the case of central VCS.
2.5. Simple and productive tool
Once the developers are comfortable understanding the core concepts and features, developers will be more productive. Developers can also commit the code in a modular fashion and collaborate with other developers without impacting other developer’s workspace.
“Distributed VCS” is highly scalable when compared with “Centralized VCS”, especially in open source projects where millions of developers contribute and a task that cannot be accomplished by a traditional version control system.
2.7. Open source
Git is open source and free. Moreover, developers can work on open-source projects on various platforms like Github.
3. Disadvantages of distributed version control systems
Now let’s see some of the drawbacks of a distributed version control system as well.
3.1. Steep learning curve
Learning Git will take some steep learning curve and often confusion and frustration for developers coming from other traditional VCS tools. But once the core concepts are understood it’s a charm to work with.
3.2. Support for Tools and IDE’s
Although a lot of tools and plugins are available to be integrated with IDEs, there are not many of them are present as in the case of SVN or perforce. Although the git bash of one of the popular tools which can be leveraged if coming from a Unix background.
Happy Learning !!