Types of Version Control System
Hey there! Hope you’re doing well.
In the last blog, we saw why we need the Version Control System with my Major Project example. Here, we are going to learn about the different types of Version Control System.
By now, we know that the version control system tracks changes to a file or set of files over time. There are three types of version control system:
1.Local Version Control Systems: Think of this as a VCS but without a remote repo. You manage and version all the files only within your local system. There is no remote server in this scenario. All the changes are recorded in a local database. As we can see in the image below, every developer has their own computers and are not sharing anything.
2. Centralized Version Control Systems: Here, there’s a central repo shared with all the developers, and everyone gets their own working copy. Whenever you commit, the changes get reflected directly in the repo. Unlike distributed systems, developers directly commit to the remote. Which means they may affect files knowingly or unknowingly.
3. Distributed Version Control Systems: In distributed systems, there is a local copy of the repo for every developer on their computers. They can make whatever changes they want and commit without affecting the remote repo. They first commit in their local repo and then push the changes to the remote repo. This is the type used majorly today.
In the Centralized VCS, every commit was directly happening to the, say, remote repo. But in distributed VCS, it first happens in the developer's local repo, and then they send those changes to the remote. Remote repo is a git repo on a server hosted by any such providers like GitHub, Bitbucket, etc.
When you commit changes in a centralized system, the changes are directly visible to others as you commit directly in the remote. But in distributed, you first commit locally, and it will not allow others to see until you push it to the remote. Likewise, when others commit a change in a centralized system, you can directly see them, but you need to pull changes in the local repo in distributed systems after they push it. So, distributed systems can also be beneficial in having only necessary/updated/completed code with everyone rather than having even experimental code like in Centralized systems.
System Failures
In a Local VCS, say, if your hard disk gets corrupted or you lose the file, you lose everything related to it, including all the changes. Similarly, in the Centralized VCS, if you lose the repo, everything is just gone. But in a Distributed VCS, even if someone’s local repo is corrupted or the remote doesn’t work or is deleted, or anything happens, there is a copy available with other developers. So you can take it from them, push to remote, and everything is back on track, just like before. There is no problem of single-point failure in Distributed VCS. You always have your code safe with fellow developers.
Version Control Systems out there
There are a lot of VCS softwares in the market. You can find a list of all those on this Wikipedia page. Although there are many available, “Git” is the most widely used today. It is written in C, Perl, and various other scripting languages.
The detail about git will be given in the next blog. Till then, have a nice time learning.
My name is Harsh Seksaria. I like to write about the topics simplifying them as much as possible for you to understand without unnecessary effort. Still, sometimes something may not be very clear. If you find any mistake, error, or you have a suggestion, just mail me. I’ll try to improve it asap.
My email: harsh20.freelance@gmail.com
My LinkedIn: www.linkedin.com/in/harshseksaria
