Skip to main content

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.

For Freelance Work & Queries Contact me by Email Id

               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 S" --- VC will save this file with version number 1

now if you edit this file as "Hi my name is SR" -- VC will save this file with version 2
now if you again edit this file as "Hi my is SR" -- 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 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.


Contact support@linuxforeveryone for any Freelancing work on Linux Servers

Subscribe my YouTube Channel 

Like My Facebook Page 

Browse the Best in class Web Hosting Plans


  1. I read this article, it is really informative one. Your way of writing and making things clear is very impressive. Thanking you for such an informative article.Cheap Linux VPS


Post a Comment

Popular posts from this blog

Solution and Step to fix CVE-2019-5736 Vulnerability - Docker

Recently a new vulnerability has been discovered in the the internet market having target to Docker services. What is this Vulnerability: In short, Docker service uses another service called as runc which is container run time to spawn and run containers. which simply means if docker task is to create docker images then runc task would be running them and attaching a process to container. So as per the recent discovery by the maintainers of runc, the code of this service was having some bug which can be used by attackers to gain the root level of access of the host machine on which docker containers are running. How it can be Exploited: This vulnerability can be exploited in two ways (1) if the docker images are in use is vulnerable making the containers build from it vulnerable also (2) if somehow attacker got the access of containers and then trying to exploit using the bug present in runc and trying to get root privileges. Solution to Fix Vulnerability: Ce

How to Generate CSR using Openssl in Linux

Before Generating CSR ,let see what is Openssl. It is nothing but a core library ,which is used for general purpose in cryptography,it is an open source product which work towards the implementation of SSL and TLS protocols. Talking about openssl, some people called the certificates generated from openssl as "self signed certificate". lets go towards now,creating CSR and private key using openssl command, Just log in to any of your Linux box and run following command as  root user  replacing the required information as per your need . [root@SVR home]#   openssl req -new -newkey  rsa:2048 -nodes -sha256 -out domain_name.csr -keyout domain_name.key -subj "/C=US/ST=state/L=locality/O=organization/OU=organization unit Dept/"  You will get output like : Then check whether ,all the information we have entered ,while creating CSR is proper ,by decoding the CSR from some online tool. First do the cat to the csr file [root@SVR home]#  cat

Multiple instances of redis

In the last post I have covered how to install redis server on Centos/Rhel using rpm method and yum method and some troubleshooting skills. In this post i am going to cover how to install and configure redis to run with multiple ports.                                                                           But why we need more ports ? If you have read my earlier post , you already know that by default redis runs on single port 6379, which any one can use it for small website to cache the data. But for heavy website like magento we need to use additional ports along with 6379 to serve different cache from different ports. Like in Magento there is simple cache which is normally stored under /var/cache directory. Then there is Full Page Cache which is stored under /var/full_page_cache and session cache which is stored under /var/session_cache. Note : Discussion about cache/full page cache/session is not under the scope for this document.