26 April, 2017

know your GIT server

If you are a developer you might be familiar with version control in your dev life. Even if you are system admin working on Windows/Linux/Unix then also you may come across version control.

               The point is if you know it its Good :) but if you do not know there is no need to worry. I will try to explain it to you as easy as possible.
What is Version Control

A version control (VC) is a system which keeps an eye on your files (which you provide to him) over a period of time for all changes you are doing like updating, deleting etc and making a data for all these changes you are doing on files.

Version Control normally was divided into 3 categories.

1) Local Version Control System
2) Central Version Control System
3) Distributed Version Control System

Let see each Version Control one-by-one 
Local Version Control System

Before Local version control introduced, developers normally keep different versions of their code in different directories on their machine, people do this even today which are not aware of any Version controls. But this method has some issue and keeping in mind those issues and difficulties to manage code, Local version control system was designed. 

Example:   There is file having data "Hi my name is Sushil" --- VC will save this file with version number 1

now if you edit this file as "Hi my name is Sushil R" -- VC will save this file with version 2
now if you again edit this file as "Hi my is Sushil R" -- VC will save this file with version 3

Doing so will help you to fetch any files with their version number in future requirement. let say I want file having version 2, then using VC I can easily fetch that file.

Central Version Control System

Now we talked about VC which can be present on the Local machine (inside your local network) accessible to you only OR it can be present at some remote location accessible to others also.

Now think about a VC which is present at some centralised location and everybody in your organisation is having access to it.

here, when you request file1 to make edits, version control will provide a copy of file1 to you, simultaneously when another user request same file, version control provide a copy of file1 to him as well.

Now both can make changes on  file1 and upload their changes on this centralised location server. here the scenario is like a central control version server serving files to different users and keeping versions of different files.

Distributed Version Control System

Above method also has its own flaws, because as the time passed, developers started interacting with other developers around the world and users present on other systems outside of their central control version boundaries. One of the main issues was a single point of failure of centralised systems.

 To overcome this new architecture was introduced which was termed as distributed version control system.

Here, Users don't just fetch the files, but instead fetched complete folder having their code, called as repositories.

Repositories are nothing but a folder having all your files which you commit to the Distributed control version system.

Example: If you are working on project ABC.com and if you are having all the code files for this project with you, you can create a folder in DVCS with the name as abc which will then called repository. and upload(Or commit ) your files into that abc repository. 

You can then pull your abc repository, make code changes in any file and then can push changes on DVCS.