DevOps Tools GIT Online Training

GIT Tutorials

Devops Tools Online Course syllabus

GIT      Jenkins     Puppet       Ansible      Docker      Kubernetes      Selenium      Nagios      Maven   

MODULE 2

Types of VCS
Differences between CVCS and DVCS
What is GIT
GIT  Architecture
GIT installation
Git commands
Working with GIT
Creating repository Cloning
check-in and committing
Fetch pull and remoteBranching
Creating the Branches
switching the branches
merging the branches

GIT & VCS Intoduction Video

 

VERSION CONTROL SYSTEM (VCS)

WHAT IS VCS? 

                        What is Version Control System?  This is nothing but a software which will help (or) which will allow Developers to work simultaneously and also it will help us to have a detailed log of each commit we were doing.  And it also helps in maintaining history of every change.  What is all that means let talk about Version Control System and understand how it works. 

 

What is a Version Control System? 

                                               VCS is nothing but a software that allow Developers to work simultaneously.  What is meant by this? How it will allow Developers to work simultaneously.  To understand this let us take a simple example. Let’s say this is a project directory where we are having a project work which was on some remote location. And let’s say there are a couple of Developers, let’s say A and B working on this ­­­repository.  Whenever these Developers have to make any changes to the project, they had to download it from the remote.  That’s nothing but pull or in simple we can say download it to the local system then work on it.  

                                   Let’s suppose ‘A’ have pulled the project work to his local system and  ‘B’ have pulled.  And ‘A’ have making some changes in file 1, so ‘B’was also making changes on the same file.  So once ‘A’s work is done , he wants to put the file back and he put the file back to the remote repository on day 1, let’s say B was still working on it and his work is done on day 2 and now he want to put the file back on day 2.  Finally A has put the file back on day 1 and B has put the file back on day 2.  Finally, the file1 present here will have only the person B changes because person A changes were overwritten by the person B changes without knowing.  

 

                                               Means this is not done knowingly, it was done unknowingly by mistake.  Like B does not know that he have overwritten the changes of A, and A does not know that changes getting overwritten by B changes, meaning both are trying to work on the same the file because there was no system which can take care of it.  The file was getting overwritten.   So, imagine there could be a team of ten Developers or Five Developers, so if this keep on repeatedly at some point the project will be in a very serious situation.  And So, to avoid this problem, we need a system which will take care of this, and that which will not allow one person changes to be overwritten by the other.  Means we need a system which will take care of the files without getting overwritten, without getting missed and no person changes should be lost.

 

                                          So such a system is nothing but Version Control System.  Meaning Version Control System will allow Developers to work simultaneously.  Here could be any number of Developers working on the program files of the project work.  So the file should not be messed up, should not be corrected, one person changes should not be overwriting the other.  So such a system is called Version Control System.  In VCS if this is the case like person A is placing the file, person B also making changes to the same file it will not allow to overwrite, it will give you some warning or error message, saying that already the person A have made the changes.  How do you want to keep the changes in the file?  Whether you want to keep only one person changes, so that nothing but Conflicts.   We need to resolve the Conflicts so that’s what is Version Control System does, that’s one of the things which allow the Developers work simultaneously also the other thing is let’s say we made some changes and the project was working fine till 9.00 AM IST today.  But 10.00 AM we got some problem.  Application crashed, there was a serious issue, the business went down.  Right immediately we need to identify the issue.  So, Developers will be concentrating on writing the code meeting the client’s expectations.  So again, here we need a system which can have a detailed log of what are all the changes done to the project.  

 

                                          Like what changes were done at what time, on which file, at what time, all these will be tracked by this Version Control System having a detailed log of any change happened at any time and again there comes another need like maintain the histories of revisions.  We may have different versions of the file, different revisions, we may have.  So the complete history should be there.  Backup should be maintained.  Files should not be deleted or overwritten.  Let’s say we were working on Version:1 client came and say asked to modify it, make some modifications, always have different versions don’t overwrite this file or don’t delete the older version, have backup of them, create new versions.  Because at some times client may want to revert back for the changes.  So whenever they want to revert back for the older versions don’t ever delete them, because if it is deleted, again it is a rework.  So always maintain the older versions.  So, which is again done through this Version Control System.  

 

                                    So Version Control System is nothing but the software which will help us means is a system which will allow Developers to work simultaneously which provides with a detailed log of what happened, at what time, on which file, on which line and by whom.  All this detailed log can be provided.  It will also provide the history of versions for each file.  It will also help in making backups.  So, that what a Version Control System does which is a very important in Real time, which helps the Developers to work collaborated.

WHAT IS GIT:

                    In this lecture let’s try to understand what git is?  Git is the free and open source Distributed Version Control System designed to handle projects of any size with great speed and efficiency.  And why Git is so famous?  To understand why git is very famous and more widely used, lets learn and look into the features of git.

a.) Branching and Merging: 

                                            This makes this very superior to other, when compared to any other Version Control System.  The branching model in git allows to have multiple branches which have completely independent to one another and also when we are pushing the branch, pushing the code to remote, we can choose which branches should go to the remote.  So, this feature makes git so unique and so powerful.

 

 

b.) Small and Fast:

                                Git is very fast in all the operations.  Generally all the operations are performed locally and this an advantage over the other Centralized Version Control Systems like SVN, TFS and all, where they have to communicate with the Remote Repository always which needs a network connection, whereas git works very fast because majority of the tasks are done locally, so once the changes are reviewed, once the changes are confirmed, then only we need network connection to push them to Remote .  So it works really fast and also git is written in ‘C’ and it works on multiple operating systems like Linux, Windows and Mac and can handle the Repositories of any size.  Any large Repositories can be managed by git.  And comes next feature distributed nature of git.

 

c.) Distributed:

                           Every user is having a copy of Remote Repository.  So, in case of the failure of the main server, lets lay the main server crashes or anything happens, there are multiple backups available, so there is no point of failure, there is no single point of failure with git, which we see in other Centralized Version Control Systems.

 

d.) Data Assurance:

                      Data model in git ensures cryptographic integrity of every bit to the projects.  Meaning every code change we make, every commit we make is checksum with which we refer as commit id, it will generate a commit Id which will alphanumeric with a checksum, so only we can refer the code and visualise the code using this commit ids.  So, Data Assurance, grated Data Assurance e provided by git.

 

e.) Staging Area:

                            Git provides a staging area or index area which works like a layer between your working directory and local repository.  This is an intermediate area which commits can be formatted, where commits can be formatted and reviewed before they are finally finalised.  So this is the importance of staging area where it works like a kind of check before the code goes to the local repository.  This is not available in other Version Control Systems and this also makes git so unique and so powerful.        

GIT ARCHITECTURE

                            As discussed git is a Distributed Version Control System.  We have already discussed the architecture of Distributed Version Control System.  Now let’s talk about the architecture of git in particular.  This is the architectural diagram of the git.  In git we have two Repositories. Local Repository and Remote Repository.  Remote Repository is also called Central Server, where all the project code is kept.  And we create a Local Repository in our local work station.  Every individual user will have their own work station.  So Local Repositories resides on the Local work station.  Now from remote we get a copy of Local Repository using git clone or git pull commands. 

 

                         What are the differences between git clone and git pulls?  we will talk about as we go by.  So initially we will get a copy from the Remote which is nothing but a Local Repository.  Again, we don’t work directly on Local Repository, there is something called working directory, when the actual work happens means it’s like another directory or a folder where we create our project files.  And once we create the project files we need to first add them to a staging area or index area. This is called a virtual layer between working directory and Local Repository. 

 

                                 So first we should add the files, add the project work to the staging area, from staging area we have to commit the changes to Local Repository.  Till here they are confined only to individual user work station.  Only once we push the changes to remote they are available for others.  Till then they are confined to that particular user.  So, this is a Local Repository where we commit the changes. 

 

                             So indexing area or staging area is like layer between working directory and Local Repository.  So just creating a file means it is set to be in working directory, we need to run the command git add—the file names, to add them to staging area, and from staging area we can commit to the Local Repository.  We cannot add the files directly from working directory to Local Repository.  This is not possible. First, we need to add them to staging area and then only we can move them to Local Repository. 

 

                               Staging area is like an indexing or virtual layer between working directory and Local repository.  Like if we consider moving or changes to Local Repository as like a two step process, first we need to add to the staging area, then we have to commit the changes to Local Repository.  There are many advantages with this kind of implementation.  We will talk about the importance of staging area once we have do our hands on. 

 

                               Coming to here working directory, Local Repository, these two are physically the same.  They are same directories on our work station where as logically different.  Means just create a let’s suppose we had created a file, it will be set to be in working directory, unless you add a commit.  Once you add the file it goes into stage area.  From staging area we can commit the changes to the local.  Once we have changes in Local Repository, we can push them to remote, so that it is available for everyone else in the team.  So, this is how it works. 

 

                              Let us start creating a Local Repository.  Local Repository can be created in different ways.  We can get a copy from the remote or else, initially let’s suppose it is a new project, the is nothing on remote, so we can create a project on a Local Repository, the once the project is ready, we can push to remote.  So first let’s create the Local Repository in our work station, considering it’s a new project.  There is nothing on remote, so first we will create a Local Repository, then we will create some files and will learn pushing them to remote. 

 

HOW TO INSTALL GIT

                                    Let’s see this is an instance on GCP which is sent to its instance, now let us first install git. 

If we run a git command, we can see that git not found, meaning git is not there.  Let us install git.  Git can be installed very easily using a single command 'yum install git –y'.  It is installed now.  If I run "git command, it shows lot of output.  Means git is installed. 

Phone: 91-9966-5923-95

  • Facebook Clean
  • Twitter Clean

 

© 2020by NEWAXIS.in