There are a number of VCS out in the market. So, it might be confusing to select the right one meeting your expectations. That’s why we want to put all key features of major tools together and guide you to select the right one.

In that very point, it is beneficial to categorize VCS according to the type of their architecture. Three existing groups are;

Version Control Model Categories

Local: The simplest version of the three is local and it is very common. Keeps track of files within local system (you may count that technique an advanced version of copying files to another folder to have backups). Help developers to record changes in a reliable manner. Works well for personal projects.

Centralized: Centralized VCS has been developed in order to support developer collaboration on code base (Local VC doesn’t provide wise ways for collaboration). This type of systems have a main server that keeps track of all changes that developers commit throughout time.  So, developers get the latest version and send back their changes.

However, this type of architecture has its own downsides. The biggest problem is possible failure of single code base. In case of a disk corruption or similar failure, entire history of project except local copies will be lost (the same as local systems). When you keep everything in a place, risk of loosing them increases exponentially.

Besides, problems in availability effects collaboration during the cut. No one can pull or push the changes to local copies.

CVS, Subversion (SVN) are two major systems using this type of architecture.

Distributed: This model offers the same life-saving advantages. Each developer works directly on their local repository (commit) and changes are shared between repositories as next step (push).

As all developers have the entire history of the codebase (not just the recent snapshot), it drastically decreases the risk of loosing the base and the changes throughout time. If any server dies, any of the client repositories can be copied back to server to restore it (Sounds familiar to Blockchain?).

Git and Mercurial are most-widely used tools using this model.


Most Widely Used Version Control Tools

Here are the three proven source control tools dominating majority of the market. Listed with fundamentals pros and cons.

Concurrent Version System - CVS

Also known as, Concurrent Versioning System is a free revision control system. The oldest among four VCS listed here.


  • Open-source
  • Cross-platform support (Windows, Linux, Mac)
  • Forerunner of modern revision control systems


  • Centralized
  • No update since 2008
  • Limited community and usage
  • No checksum control to verify data integrity (May lead corruption in time)
  • No atomic check-out or commits (If any problems happen during multiple transfer, system does not roll back updated files to the state before)

Apache Subversion - SVN

Subversion is an open-source, centralized version control system developed by Apache Foundation. Chronologically dominating tool after CVS. Also, there are still organizations that rely on SVN for their projects.


  • Open-source
  • Stable versioning
  • Community support (still)


  • Centralized
  • No offline work support
  • Slower comparing to Git, especially merging large branches
  • No pull request option which Git has
  • Not that cool anymore!


Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. (

Nowadays, Git has become a de facto standard for Version Control System selection. But, why? What are the advantages using Git over other version control systems? Here they are;


  • Distributed architecture, makes offline work more practical
  • Branching is easier and faster
  • Pull requests
  • Many platforms offering Git service with additional features
  • Community support
  • Most popular!


  • Security can be problematic. User has full access to repository. No per folder or branch security
  • There is no locking for files

Git Platforms - GitHub, GitLab, BitBucket

Assuming Git is the tool you decided to use for your organization, a new question arises. Which Git? Are you going to setup a Git server for yourself? Or going to use a platform? Even though the answer depends on your expectations, many people choose to use platforms to take advantage of additional features, such as user authorization, tool integrations etc.


GitHub, GitLab, Bitbucket, AWS etc. are the platforms offering Git service to their customer with additional functionality (they all have main capabilities anymore) and different licensing model. Nowadays, political stance, community support and tool stack are main factors affecting platform selection.

So, which is your favorite? Please join the poll by answering only this question.