Version Control System - The What? Why? & How?
What is a Version Control System?
Version Control System also known as Source Code Management system helps development and operations team maintain project source code files and other delivery related resources with ease.
Why is it used?
Project source code files which run your application need to be stored, shared and tracked reliably in order for your project use them and work as desired. A version control system aids development and operation teams with storing, sharing and tracking of code files with minimal effort.
Now why do we need to share and track these code files?
Share - In a typical enterprise environment, there will be lot of developers who will be working on single project. All these developers will need access to updated code files at all times to work in parallel and seamlessly. Track - You need to keep track of history of changes in the files, so that in case if you have to go back to an older version or you want to compare what has changed over the course of time you can get right on it.
Version control system helps immensely in sharing and tracking changes.
There are three basic types of version control systems:
1. Local Version Control System 2. Centralized Version Control System 3. Distributed Version Control System
Each of these differ in ways they address source code management. Let us see how each one work.
How does it work?
Local Version Control System:
Local version control systems help store and track code changes on your local machine. With local VCS, you do not have the ability to share the changes with anyone but you. This type of VCS is preferred if you have to locally maintain history of code changes but there is no necessity to share. This is preferred if you are working on your pet project or a freelance project.
GNU Revision Control System, one of the earliest version control systems designed to work with UNIX machines is an example of local version control system. It stores the latest copy of your code files and reverse differences called deltas. Reverse differences are compared with your latest code copy to track history of changes or to revert back to an older version.
Centralized Version Control System:
Centralized Version Control System uses client-server architecture to implement version control. In a centralized version control system, you have a centralized version control server which stores, shares and tracks your changes. If you need access to the code, you connect to VCS server using your VCS client, access the repository (place where your code resides along with it's change history) and pull/checkout the code to your local machine. VCS clients could be command line or can be graphical user interface. For Apache subversion centralized version system apart from command line interface you have GUI tool Tortoise SVN.
Every time when you need to pull code to your local machine, push your changes to central repository, update your local code copy with latest repository data or check the history of changes, you need to connect to your version control server using your client.
Whenever there is a change to a file, VCS server tracks of the each file level changes (Δ) as shown in the picture below. So your new revision of the file will be (old file + Δ) which will be made available for everyone.
Distributed Version Control System:
In Distributed Version Control System, you have your own local repository. Additionally you can connect with any other individual's local repository to pull changes or to push your changes. Basically it's a local version control system which can talk to any other individual's local version control system. Git is a distributed version control system.
But the above flow of any individual developer having the ability to push or pull changes from another individual's repository becomes messy and not manageable when there are multiple developers who work in parallel on same code files. Few developer's repositories may be in sync and few may not be.
In order to resolve the problem, in an enterprise environment, communication between individual developer's repository is not advised. Instead there will be a remote repository where everyone will connect to share the code and collaborate. So this how it works:
Each individual will have their own local repository, they will keep making their changes in their local repository and track the same locally (files+history of changes). Whenever they need to share the code with a fellow developer or they have completed a module, they will push the changes to remote repository, which can then be pulled by the fellow developers to use on their local repository. This provides the advantages of both centralized and local repositories. You don't have to rely on centralized server all the time to access your history of changes or to commit your code. You don't have to worry about losing code files and changes when the central server goes down as each individual have their own local copy with history data. As you repository is local, distributed VCS is faster than centralized VCS to work with.
Remote repositories are usually hosted on git hosting platforms such as github or bitbucket, to which you connect from your git repository to collaborate. As opposed to using a hosted remote git repository, you can also setup your own git server which can hold your remote repository and cater to developers too.
Whenever there is a change to a file, DVCS such as Git unlike it's predecessors, stores snapshot of the changes in particular revision rather than the file based changes increment (Δ), as illustrated in the picture below.