Why use version control System.?
To understand this Suppose you are a software developer. One day you find a client. The client told you to build an application so what you did was, you created a folder in your system and inside that folder, you created many files. .py .php .java etc after coding you went for a demo to the client and he said all are good but I need some changes So you made some change to the code and after some time you went for a demo again but again the client suggested some change and one fine day he requested that I want that Code that you had written in first day.
Now any Sane developer would get frustrated because he can't remember all the changes he made in those files in the same directory. He had not backed up or stored changes made in a folder so to solve this issue here comes the need for a version control system.
So what we understood from the above story.
✔Every version has to be maintained because maintaining multiple versions manually is a very complex task for a developer.
✔Every change should be tracked because multiple developers are working in an organisation.
🤷♂️ who did the change.?
🤷♂️ when he did the change.?
🤷♂️ which change he did.?
✔We should not overwrite our code.
The above needs are fulfilled by a version control system.
Types of version Control System.
#Centralized Version Control System.
Introduction:-
It is very easy to set up and easy to use.it is good for a small number of files and small projects. The total project code is being stored at the Central depository server. version control is happening at only one place that is the central repository server. Every developer is required to connect to this Central repository server to continue their work. All Commit and checkout operations will be remote, on the Centralised Repository Server and not locally(In the working directory). Examples of centralized version control systems are the CVS, Perforce, SVN, and TFS.
Limitations of centralized version control system.
Single point of failure: The total code is stored in a single place which is the central repository server if something goes wrong with this Central depository server recovering it is very difficult.
All checkout and commit operations will be performed by connecting with the remote Central depository server which means all developers should be connected with the Central repository if network outrages, version control will not be available for the developers.
Low performance: All checkout and commit operations will be performed by connecting with the remote Central repository server and the operation will be performed over the internet, these are not local operations so performance would be low.
To overcome this limitation we have to go for a distributed version control system.
#Distributed Version Control System.
Introduction:-
Its repository is distributed; each developer has their repository means every working directory has its local repository. All commit and checkout operations will be performed locally and hence performance is more because no network is required between the working directory and repository, all-time version control is available, and there is no question of a single point of failure.
From the above Drawing:-
I have taken only one developer's working directory but in actuality, multiple developers are working in an organisation. Commit and checkout are performed locally and there is no need for a network. Examples of distributed version control systems are Git, Mercurial, fossil etc.
Now as I have said there will be many developers then how do they merge all their code? The answer is using a Remote Repository. and this remote repository is known as GitHub, GitLab, bitbucket, etc. It should also noted that this remote repository is being used to share code with peer developers and the final delivery of project code will be done from this remote repository only. See the below image to get an idea.
#The general meaning of Push-Push is an operation by which one developer sends changes of his repository to another repository.
#The general meaning of Pull-The process of getting files from another's repository to our local repository.
Git(Distributed Version Control System)
Introduction:-
Git is a distributed version control system. It is open-source and was developed by Linus Torvalds. It provides support for multiple platforms like macOS, Windows, and Linux.
Features of Git:-
#Git is distributed so have the following benefits.
✔No single point of failure because every developer has a local repository.
✔performance is more because checkout and comment operations are performed locally.
✔Developers can continue their work even without a network because they don't need to connect always to the remote repository.
#Staging Area. (also known as index, cache, logical, virtual area)
✔Git has a very good feature called Staging area other version control does not have this Staging area which has many benefits.
✔In between the working directory and local repository there is one special layer or virtual area to store our files before committing that place is nothing but a Staging area. The advantage of stating area is that we can cross-check or double-check our changes before committing. if something goes wrong we can remove the file from the Staging area to the working directory and again debug.
✔12 GB file we have to store in SVN but git automatically does hashing or takes snapshots of data by Cryptography to reduce the file size. (SHA-1 hash function is used in Git.)
#Branching and merging:-
✔We can create and work on multiple branches simultaneously and all these branches are isolated from each other. It enables multiple work flow and then we can merge all the branches to give rise to a single branch.
Git Architecture:-
# In Git there are four Areas.
✔Working Directory ✔Staging Area ✔Local Repository ✔Remote Repository.
# Git has two types of Repository
✔Local repository ✔Remote repository.
📄Usually, the total project code will be available in the remote repository.
📄The current work of the developer will be stored in the local repository.
📄New files will be created in the working directory Once work is completed we have to add these files in the Staging area for this we have to use the git add command.
👍Git clone means to create a new local repository from the remote repository. (cloning means creating an exactly duplicate copy) generally used by new developers who joined the organisation.
👍Git pull means to get updated files from the remote repository to the local repository.
👍Git push means to move files from the local repository to the remote repository.
👍Git commit means staged changes will move to the local repository. Every commit will generate a commit ID. For every commit git records the author name, email id, time stamp, and commit message.
Life Cycle of File in Git:-
Every file in git is one of the following 4 stages.
Untracked(untracked by git) state
Staged state
Modified state
In repository/committed state
Untracked state:-Every New file will be created in working directory, git does not aware this new file. such type of files are said to be in "untracked".(untracked will be removed when we bring the files in staging area with the help of git add coommand).
Staged state:-The files which are added to Staging area are said to be in staged state.
✔The staged file would also be available in working directory because git add command does not move the file .It just copy file's state and put in Staging area.
✔git add a.txt - To add only one file(a.txt) to Staging Area.
✔git add . - To add all the files to Staging Area.dot means all.
✔git add a.txt b.txt c.txt - To add multiple files to Staging Area.
✔git add *.txt - To add all .txt files to Staging Area.
In Repository/Committed state:- File which is committed is said to be in repository(Local) state or committed state but when we do git commit the first time it will ask username and email for this be we will be using git config --global user.email "your email" and git config --global user.name "your user name". It will also ask commit message for this we will use git commit -m "followed by a commit message".
Modified state:- File which is already tracked by git but is modified in the working directory is said to be in a modified state.And which files are tracked by git ?? Always remember the files which are added to the Staging area or committed are only tracked by git.
Git practical(for Windows):-Download git for windows from Google and go for (64 bit git for windows setup),Install it now create a working directory( folder) in any drive of your PC after that we have to request git that we need version control for this folder so for this we will open git bash by right Click on PC screen. Now from CLI we will use git init command.This command actually means we are requesting git to provide an empty local repository inside our working directory folder so that version control can be implemented.
After this you can use "git add" command to add the files in Staging area and from there you can use "git commit" to commit the stage changes to the local repository. I am not completing every aspects of git here ,just trying to clear some basic knowledge about git that paralyze begineeers to understand git but I am going to define some daily used command which will help you to understand git more easily.
**git init-**We are requesting git to provide local repository in working directory so that version control will be applicable for that working directory.
**git add:-**To add files from working directory to Staging area. once we added files to Staging area then git tracks these files and ready for commit.
**git commit:-**Saged changes will move to the local repository. Every commit will generate a commit ID(40 characters). For every commit git records the author name, email id, time stamp, and commit message.
git status:- It shows the current status of all files in each area like untracted files,modified files, and staged files.
git log:- It provides detailed log information like history of all commits.Eg. Commit ID(40 Character),commit message,author name and email and time stamp.
Subscribe to my newsletter
Read articles from Sumit Kumar directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Sumit Kumar
Sumit Kumar
DevOps Engineer