Introduction to GitLab CI | What is GitLab CI | GitLab Tutorial For Beginners | Part I

hey what's up everybody my name is moss and  welcome to this tutorial series on git lab in   this tutorial series i'm going to teach you how  to utilize some of the core features of gitlab   in this video i'm going to walk you through the  road map of topics that we're going to cover   in the tutorial series as well as the learning  objectives and who this course is made for   i'll also cover the first and  second topics of this course   in this video as well so without  further delay let's dive right in   so for the first topic of this video we are going  to be answering the question what is git lab and   then i'll walk you through the basics of git but  before i do that let me introduce myself my name   is moss and i'm an experienced devops engineer  with over six years of experience in industry   now let's take a look at the roadmap of topics  that we'll be covering in this tutorial series   as i already mentioned our first topic will  be answering the question what is git lab then   i'm going to walk you through the basics of git  and after that i'll introduce you to the major   components of the gitlab interface once you're  comfortable with the gitlab interface i'm going   to introduce you to the basic workflow in git lab  called the git lab flow and once i've given a high   level overview of the gitlab flow we'll perform  hands-on activities that utilize the gitlab flow   we'll then dive into more advanced  topics starting with how to do ci cd   in get lab i'll then show you how to  migrate your jenkins pipelines to gitlab ci   after that we'll explore gitlab's packaging  and releasing features and finally i'll show   you how to integrate the lambda test platform  with gitlab ci to perform cross-browser testing   now let's quickly go over our learning  objectives the first learning objective   is to give you an introduction to gitlab ci you  will also learn the fundamental commands of git   you will know how to work in gitlab using the  gitlab flow you will also understand and be   able to perform ci cd in gitlab you will know  how to migrate your jenkins pipelines to gitlab   and you'll learn how to deploy software using  gitlab's packaging and releasing features   so who is this course for this  course is made for devops engineers   software teams who want to migrate from jenkins  to gitlab and developers whose team uses gitlab the prerequisite to this course is that you  have access to gitlab or a private instance   of gitlab so you should have a user account  on whatever gitlab instance that you're using   you will also need a recent version  of git installed on your machine now let's get into the first topic what is git lab   git lab is an open source software development  platform and at its core it is a source code   management system but it also offers additional  functionality like cicd on top of being a source   code management system and as you can see on the  right gitlab describes itself as a devops platform   so what's the difference between git  and git lab git is a version control   system you use git to keep track of changes  made to source code files in a code base in contrast gitlab is a  source code management system   so you would use gitlab to host git repositories  so that they can be shared with other people on   your team similar to how you might upload  and share files to dropbox or google drive   you're doing the same with gitlab but for  source code so why use gitlab gitlab enables   collaboration among software teams with the  gitlab flow git lab also has built-in ci cd   functionality gitlab is highly interoperable and  it can integrate with other tools these are just   some of the features that gitlab offers  but there are plethora of other features   now that we have a high level understanding of  what git lab is let's dive into our next topic   okay let's get ourselves up to speed with some  basic git commands this might be a refresher if   you're already familiar with git but if you're  not let's go ahead and verify that you have   get installed on your machine i currently have my  terminal open and to verify my installation of git   i'm going to invoke git and i'm going to pass in  the dash dash version option and this will return   the version of git that is installed on my machine  if it's installed and as you can see i have   get version 2.33.0 installed so the first git  command that we should cover is the git init   command and if you don't pass any parameters  to the get init command it will initialize the   current directory as a git repository so if i were  to execute the get init command as it is right now   it would initialize the lambda test folder as a  new git repository and it makes sense to use git   init like that if you have a pre-existing code  base that you want to check into version control   and initialize as a new git repository however if  you didn't have a pre-existing code base that you   wanted to initialize as a git repository then  what you would do is you would pass the desired   name of the git repository that you want to  initialize as an argument to the get init command   and that's the option that we're going to use and  let's call our git repository test hyphen project   okay and what this is going to do is it will  create a subdirectory under the lambda test   directory and that directory will be called test  hyphen project and that will be our git repository   so i'm going to go ahead and execute the get  init command and you can see at the bottom here   it says initialize empty git repository in and  then it specifies the path of the git repository   and then directly above that it  gives us an informational message   about the name of the default  branch in our git repositories   and it gives us a couple of commands to rename  the default branch in our repositories so let's   go ahead and do that let's execute the first  command here which is git config dash dash global init dot default branch and then let's  set the the default name to the default   branch of our git repositories as main  and then to execute the second command   we need to change directories into the git  repository that we just created so i'll go ahead   and cd into the test project directory and then  to rename the branch of our current git repository   to main we will execute git branch dash  m and then the target name which is main   so if we take a look at the test project directory  it should be empty let me clear the terminal real   quick and if i do an ls there's nothing in  the test project directory if i do an ls-al   to see the hidden folders in the directory  you'll see a hidden folder called dot git   and the dot git directory is what makes  the test project directory a git repository   without the dot git directory the test project  folder is just a folder it is not a git repository   it's not tracking changes to any of the files  within the test project folder so if i wanted   to verify that the test project directory is a git  repository i can look for the dot get folder and   i can also do a git status inside of the directory  and this will also tell me whether or not i'm in a   git repository and as you can see from the output  of the git status command we are currently on   branch main which is the default branch that was  created when we use the get init command and then   it says that there are no commits yet so we  haven't generated any new git commits in this   repository so this repository is essentially  a blank slate it has uh zero git history yet   and then in the last line of the output  it says that there's nothing to commit   so the git status command essentially tells us  what the current state of our git repository is   so if we've added any new files to the test  project directory or changed existing files   within the test project directory when we  perform a git status git status will show   all of those changes in the output git status is  a very useful command and you'll find yourself   running git status very frequently when you're  using git and working inside of a git repository   now this git repository isn't very useful to us  if there aren't any files in the project that   we want to version control so what we can do  is add new files to the test project directory   and commit those new files on the main branch but  if we do that then we're not taking advantage of   of git's one of git's most powerful features which  is branching so what's important to know is that   the main branch in a git repository and it's  not always called the main branch sometimes it's   called the pristine branch or the stable branch  is a branch that is supposed to be code that has   no bugs in it it's supposed to be deployable code  that can go to the customer and because of that   if you're a developer who wants to work on a new  feature working on the main branch is dangerous   because while you're working on that feature you  might commit some changes that cause other parts   of the code base to break and if the main branch  breaks that breaks the code base for everyone   not just for you so it's really important to  understand as a developer you should never be   committing changes directly to the main branch  of your git repository so if you're developing a   new feature in a git repository you always want to  make sure that you're not developing that feature   on the main branch you should be developing it  on its own dedicated branch and you can think of   a branch in git as an entirely separate copy of  the code base it's a copy of the code base that   you can work on and experiment in and develop your  feature in without having any impact on the main   branch of the code base so you would develop your  feature in this branch or this copy of the code   base and once you've completed your feature and  you're confident you've ran tests on the feature   and you're confident it can be merged into the  primary version of the code base you can actually   use git to merge your branch and your feature  into the main version of the code base   so we are going to follow the best practice  of creating a branch in order to make changes   in our repository but before we can actually  create a branch we do have to generate some   history so right now in our git repository  we have no commits made in the repository   so we have to make at least one commit in the  repository so that we can create a new branch   and use that branch to develop a feature so  what i'm going to do is create a new file   in this git repository i'm going to create  it using vim so i'm going to invoke vim   and feel free to use a different uh  editor if you prefer a different editor   but i'll call the file hello dot text okay and  inside of this file we'll simply say hello okay so if i do an ls you can see that we now have  the hello text file in our git repository   and how does adding the hello.txt file change  the state of our git repository well we can   check the state of our repository using the get  status command so i'm going to do git status   and you can see now we have a little bit  different output in the git status command   it says that we're on branch main there  have been no commits made to this repository   and then there is one untracked  file and that is the hello.txt file   and git is really useful in that it suggests  uh commands to use to progress through the the   workflow and it says use git add and then the  file name to include in what will be committed   so what is the get ad command and what does it  mean to add a file to a git repository and to   answer that question i'm going to pull  up the git documentation in my browser   and i'm already at the target page and just  for reference i'm at get hyphen sem.com   so in git there is a concept of a two-stage commit  and what that means is that in order to commit   changes to uh git repositories history which  means make a commit object a commit object is   what tracks a particular set of changes to a git  repository we have to use this two-stage commit   and it this two-stage commit process and it begins  with adding changes from what's called the working   directory into the staging area and if you're  wondering well how do i know whether or not my   changes are in the working directory or if they're  in the staging area it's pretty easy to check   where your change is at using the get status  command if i take a look back at my terminal   from the get status output we can tell whether  or not a change is in the working directory or if   it's in the staging area if it's in the working  directory those changes will show up in red as   they do here so this change is currently in the  working directory and we want to move it to the   staging area and what the staging area allows you  to do is commit changes that are logically related   to each other so in the working directory you can  make changes to whatever files and you can make   unrelated changes within files but you don't have  to commit all of those changes at once what you   can do is you can stage those changes the changes  that are logically related to each other before   actually creating a commit object and creating  well-formed commits is actually very important   to do so in order to move changes from the working  directory to the staging area we have to use the   get add command followed by uh the the argument of  the get add command are the name of the files or   the directories that we want to add to the staging  area and then from the staging area in order to   to create a commit object we would use the git  commit command so let's go back to our terminal   and add our hello.txt file to the staging area so  to do that i'm going to say git add hello dot text   okay and it doesn't provide any output  from that command but it did execute   successfully and we can confirm that  by running the git status command again   so now our hello.txt file is in the staging area  and how do we know it's in the staging area well   any changes that are currently staged will show up  in green and you can see here that git recognizes   that it's a new file that has just been added  to the repository and in order to commit this   file to git's history we would use the git commit  command and we can also unstage this file as   well and move it back to the working directory  and git tells us how to do that we can use git   rm dash dash cache and then the file name  to unstage this file but we won't unstage   this file we are going to follow through with  the two stage commit process and to do so we will   invoke git commit okay and if we invoke git commit  by itself uh what it will do is it will bring up   the default uh get editor and prompt us for  a commit message and a git commit message   is essentially a description a very concise  description of the change that we're making   so it's metadata on uh the changes that  we're making to the git repository so that   later on if someone wants to review the changes  made to the repository they have concise summaries   of all the changes that have been that have  been made within a single commit so we can use   git commit without any arguments or options and if  so it'll invoke your default editor and in my case   it should pull up vim and it does and it prompts  me to enter a commit message but the other option   without using without pulling up the default  editor so if i exit vim and do git commit   i can use the dash m option and this way i can  actually pass my commit message in inline with the   invocation of the git commit command so if i wrap  it in quotes i can then pass in my commit message   directly at the command line and this is the  option that i'm going to use and in my commit   message i'm simply going to say adding hello dot  text okay and end quotes and then i hit enter   and in my case it does give me a confirmation  message that a commit object was created   but if this is the first time that you're  using this git installation on your machine   then when you invoke the git commit  command it will probably ask you to   enter a username and email address for your  git configuration so that when it creates the   commit object the metadata related to who  committed uh those changes and who was the   author of those changes will show up with your  information in my case i already have those   configurations set but if you want to set those  configurations now you would simply say git config   and pass pass in the dash global option and then  we'll say user.name and then you can pass in your   name so in my case i would just say moss and then  we can also say git config dash global user.email and then you would pass in your email same as the  username i won't reset my email since i have it   uh already configured so i'm gonna do a control  c and now that we have a commit generated in the   repository we might want to review the history of  the repository at a later date so how would we do   that how would we take a look at the commit that  we just created well to do that we can use the   get log command so if i invoke git log just like  this it will show a list of all of the commits   that have been made in the git repository so i'm  going to go ahead go ahead and hit enter and in   the output of the git log command we can see all  of the metadata related to a commit so in our case   we only have a single commit and on the first line  here you can see the hash of the commit object and   the hash is the unique identifier of that commit  object and directly next to the hash of the commit   is this head and then the arrow pointing to  main what this is saying is that the main branch   is um pointing to this commit so essentially the  main branch is up to date with the latest version   of the repository and then head and the arrow  here pointing to main this simply means that   we're currently checked out to the main branch if  we made changes to the repository if we made new   commits on the repository it would be associated  with the main branch and then below that line we   have information on the author and this is  information that would have been configured   using these commands so i have the author name and  the author email address and then below that is   the uh creation date of the commit okay and then  directly below that is the actual commit message   that we provided in line when invoking the git  commit command okay so now that we've created our   first commit in the git repository when i perform  a git status we shouldn't see the no commits   message in the output of the git status command  and as you can see we don't see it all we see   is that we're currently on branch main and that  there is nothing to commit and the working tree   is clean meaning there's no changes in the working  directory that could be added to the staging area   now if we want to make any additional changes  to the git repository what we should do first   is create a branch so that we can work on those  changes on a separate branch that isn't the main   branch so let's say i want to modify the hello.txt  file and i also want to add a new file to the git   repository so the first thing that i want to  do is create a branch and to create a branch   i can use the get branch command and then as an  argument to the get branch command i can pass in   the name of the the desired name of the branch  that i want to create so let's call this branch   my hyphen feature and then i'll hit enter so  that just created the branch and i can confirm   that it created the branch uh by just invoking  git branch without any arguments and you can   see that two branches are listed in the output the  main branch and then the my hyphen feature branch   but notice something is that the main branch is  highlighted green with this asterisk and what uh   that means is that we're still working on the main  branch if we were to make any changes right now   add any new files those changes would be added to  the main branch if we were to commit them so what   we need to do is we need to uh check out to the  my feature branch so in git we call it checking   out to a branch and before we check out the my  feature branch let's run uh git log one time   and you can see in the git log output  now not only is the main branch listed   in the output but also the my feature branch and  both of the branches are pointing to the same   commit right now but also notice that the head  pointer is currently pointing to main which means   that we're uh that we're working on the main  branch and any changes that we make would be   committed to the main branch and they would not  be applied to the my feature branch so let's go   ahead and check out to the my feature branch and  to do that we can use git checkout and then the   name of the branch that we want to check out to so  i'm going to say git check out my hyphen feature   and it says in the output that we switch to branch  whoops that we switch to branch my hyphen feature   and if i run a git status you can see that we're  currently on branch my hyphen feature and that   there is no changes to commit and also if we run  git log again not much has changed but notice that   the head pointer is now pointing to the my feature  branch and it's no longer pointing to the main   branch which further confirms that we're checked  out to the my feature branch and any changes that   we make at this point and commits that we create  will be associated with the my feature branch and   they will not be applied to the main branch so  let's add some new changes to our git repository   and practice the two-stage commit process so the  first change that i'm going to make is to the   hello.txt file so i'm going to open it in vim but  feel free to use whatever editor editor you prefer and i will simply add world so be hello world  and we'll save it and i'll do a git status   and you can see in the working directory git  prompts me it says changes not staged for commit   and then it shows here instead of new file it  shows that the hello.txt file was modified and   we can either use git add to add those changes uh  to the staging area or we can use git restore and   then the name of the file to discard the changes  in this case it would remove the word world   from the hello.txt file that we just added if i  were to run git restore and then the file name   git restore and then hello.txt and  then for the next change i'm going   to create a new file and i'm  going to call it tess.txt and i'm going to say unrelated change and i'll save it and then i'll do git status again so the test.txt file is a new file which means  it's going to be listed under untracked files   git currently is not tracking the test.txt file in  order to track this file we have to add it to this   git repository's history and to add it to the the  history we have to make a new commit now remember   that i mentioned that we can stage logically  related changes together so that we can create   well-formed commits and it might be the case that  the change that i made to the hello.txt file is   unrelated to the addition of the test.txt file so  i might want to commit these changes separately so   let's exercise the staging area and commit just  the changes made to the hello.txt file and then   we'll create a separate commit for the addition of  the tests.txt file so to add the changes made to   the hello.txt file to the staging area i would say  git add and then hello dot text and then if i do   a git status we can see that the changes made to  the hello.txt file are in are now in the staging   area and then when we invoke git commit it will  only commit the changes that have been staged   uh to get's history so if i say git commit  dash m and then we'll say modifying hello.txt   i'll hit enter so it created a new  commit and then if i do git status   the change where we added the test.txt file to  the repository is still in the working directory   and if i perform a git log we should see  two commits in this git repository's history   and we do and notice now that the branches are  not pointing to the same commit anymore the   main branch is pointing to our first commit in  the repository and the my feature branch is now   pointing to the latest commit made in  the repository where we're modifying the   hello.txt file so now let's add and commit the  test.txt file so i will say git add test text   and then git commit dash m and  we'll say adding the test.txt file okay so that created a second commit so now  we have two commits on the my feature branch so if   we list the files in the test project directory we  can see the hello.txt file and the test.txt file   and if i were to cat the hello.txt file we can see  the contents of the file and it says hello world   so this is the latest version of the hello.txt  file on the my hyphen feature branch if we were to   check out back to the main branch you'll notice  that the directory structure gets updated   as well as the hello.txt file so let's  go ahead and check out to the main branch   so i'm going to use git checkout and then main and  it says that we've switched to the the main branch   and i'll confirm with git status as well and it  says that we're on the main branch here as well   so if i do an ls you can see that the test.txt  file is no longer listed in the directory because   on the main branch the tests.txt file hasn't been  created yet and similarly if we cat the hello.txt   file you can see that it's the older version  of the hello hello.txt file that doesn't say   hello world so while we made changes on the my  hyphen feature branch the history of the main   branch has remained intact nothing has changed  on the main branch we've only made changes on   a separate branch which remember we can kind of  consider almost like an entirely separate copy of   the code base it's an isolated space where we can  make changes and experiment without impacting um   the main version of the of the git repository  but if we're satisfied with the changes that   we've made on that branch then what we can do is  we can merge those uh changes and those commits   into the main branch and to merge a branch in  git we want to be checked out to the target   branch and then we'll specify the source branch  that contains changes that we want to merge   so currently we're checked out to the main branch  if i do a git status we can see that we're checked   out to the main branch and the main branch is the  branch that we want to merge changes into so now   that we're checked out to the main branch we can  use the git merge command to merge the changes   from the my hyphen feature branch into the main  branch and the only argument that we need to pass   to the get merge command is the name of the  source branch which in our case is the my   hyphen feature branch and real quickly before  we execute the command i want to do a git log   and i'm actually going to pass in the dash dash  all option in the dash dash one line and dash   dash all will show us the history of all branches  in the git repository and dash dash one line will   give us a nice uh one line summary for each uh  each commit in the repository okay so there's   three commits in total and you can see that the  my feature branch is pointing to this commit   and then the main branch is uh  kind of behind it's pointing to   the first commit that was made in the repository  so when we perform a get log after executing   the merge we should expect to see the  main branch pointing to this commit so   let's go ahead and execute the merge  i'm going to say git merge my feature   and it gives us kind of a confirmation message  saying that it performed a fast forward merge   and we have a new file test.text and a couple  of lines were changed in the hello.txt file   and we can also confirm this by performing an  ls and we can see that the test.txt file now   exists in the test project directory and if  i cat hello.txt we can see it's the latest   version of hello.txt which includes hello world  and finally let's check the history using git log   actually i meant to use git log with the  one line option in dash dash all okay   so now we can see in the output here that the  main branch is pointing to the same commit   that the my feature branch is pointing  to so it includes the changes contained   in both of these commits and since the changes  that were made on the my hyphen feature branch   are now merged into the main branch there's  really no need for the my hyphen feature branch   so i'm going to delete that branch and i can do  so using git branch d and then my hyphen feature   now there is one more very useful git command that  i'd like to show you so i'm going to go ahead and   clear the terminal and the command is git stash  the git stash command allows you to experiment   with various changes and save those changes  without actually committing them to the get   the get repositories history as a  commit so to show you what i mean   i'm going to make a modification uh to the  hello.txt file so i'm going to open it up   i'm going to add a word here i'm just going to  say hello world testing and i will save the file   so i'm going to run git status and we can  see in the output that the hello.txt file   has been modified and we can stage that change  to be committed or we can actually stash   that change where we added the word testing to the  hello.txt file when i use the git stash command   i'm taking all the changes that are in my working  directory and i'm stashing stashing them away in a   reserved location that's outside of git's history  and to stash our changes to the hello.txt file   i can either say git stash or git stash  push and that will stash the changes made   to the hello.txt file away so i hit  enter and it says saved working directory   and index state work in progress on the main  branch and if i perform a git status you'll notice   that i have a clean working  directory that change no longer   no longer exists in the working  directory and if i cat the hello.txt file   the testing word is not included in the hello.txt  file that change that i made still exists but it's   been stashed away and to see that change i can use  git stash list and it will list all of the changes   that have been stashed by git so i can see my  change in the stash at position 0 and if i want to   reapply that change to the working directory i can  either use get stash apply or i can use get stash   pop and there is a difference between these  two commands when i use git stash apply it will   reapply the changes to the working directory and  you can see here that now hello.txt is modified   if i cat hello.txt i can see the word testing  in the file now but it will not remove   this change from the stash so if i do get  stash list again i can still see that change   listed in position zero the only difference  between git stash apply and git stash pop is that   git stash pop will actually pop this uh change  off of the stash so that it is no longer listed   in the stash so if i perform a git stash clear it  will clear all of the entries in the stash i still   have my change applied in the working directory  i'll stash this change again but i'm going to use   pop instead of apply so get stash push and then  get stash list okay and then i'll do git stash pop   okay and it shows that the hello.txt file  has been uh modified and if i do git stash   list you can see that that stash entry has  been removed in later videos we'll explore   a few more git commands but at this point  you're ready to start working with git lab   and in the next video we'll introduce you to some  of the major components of the gitlab interface   if you'd like to learn more be sure to follow  our blog at lambdatest.com forward slash blog   as well as our lambda test community  at community.lambdatest.com you can also earn resume worthy lambda test  selenium certifications at lambdatest.com   forward slash certifications  see you in the next video you

Channel: LambdaTest

Views: 18,345

Keywords: Cross Browser Testing, gitlab ci cd tutorial, git commit, gitlab ci, gitlab tutorial for beginners, gitlab tutorial, Git, cicd, gitlab vs git, gitlab ci cd, gitlab ci tutorial, what is gitlab, introduction to gitlab ci, introduction to git, gitlab basics, understanding gitlab basics, What is the difference between Git and GitLab, How does GitLab integrate with Jenkins, How to migrate from Jenkins to GitLab, How GitLab CICD works, git repository, git lab, What is git, Devops

Id: qKxytMuUiJA

Length: 38min 45sec (2325 seconds)

Published: Mon Sep 06 2021