In the last post we had an introduction to centralized version control systems. In this post I will be introducing you to 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.
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 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”.
Advantages of distributed version control systems
Lets see the advantages of this approach over traditional/centralized version control system.
Each collaborator checks out the codebase into his local repository and work on the local repository. Hence all the operations will be fast since there won’t be any network call to any server.
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 centralized repository.
The developer can create as many local branches and work on the branches and then merge it 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 resides on one single server and creates lot of confusions when working on a large project.
Snapshots instead of difference
This is one of the key benefits. We can get the complete code repository for each commit that we have perform. Hence we can easily revert back to any commit without having to deal with applying the changes from the base version manually as in case of central VCS.
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 modular fashion and collaborate with other developers without impacting other developer’s workspace.
“Distributed VCS” are highly scalable when compared with “Centralized VCS”, especially in open source project where millions of developers contribute and a task which cannot be accomplished by a traditional version control system.
Git is open source and free. Moreover, developers can work on open source projects on various platforms like Github.
Dis-advantages of distributed version control systems
Now lets see some of the drawbacks of a distributed version control systems as well.
Steep learning curve
Learning Git will take some steep learning curve and often confusion and frustrating for developers coming from other traditional VCS tools. But once the core concepts are understood it’s a charm to work with.
Support for Tools and IDE’s
Although a lot of tools and plugins are available to be integrated with IDE’s not many of them are present as in case of SVN or perforce. Although the git bash of one of the popular tool which can be leveraged if coming from unix background.
In this next post, lets explore more on understanding Git fundamentals.
Above article is contributed by one of this blog’s reader Pradeep Kumar (@pradeepkumarl). He is Software Developer having more than 10 years of experience and have worked with various version control tools like SVN, Perforce, ClearCase and Git. He is passionate about technologies and love to teach them. You can checkout one of his online course on Git – Novice to Expert.
Happy Learning !!