Git Full Course - 6 Hours | Git Tutorial for Beginners [2023] | DevOps Git Tutorial | Edureka

[Music] many large organizations are now using git for Version Control as it allows them to scale their development efforts and improve collaboration across the team git is constantly being improved and updated and its popularity shows no sign of slowing down it continues to be a popular choice for Version Control and is likely to remain so in the coming years hello everyone and welcome to this session we are currently watching edureka get pull course video by the end of this video you will have a thorough understanding about git all the way from Theory to the Practical applications now if you love watching videos like these then subscribe to radio rakers YouTube channel and click the Bell button to never miss out any updates from us also if you want to learn more about git after watching this session and wish to obtain edureka's devops certification course then please see the link in the description below so let's begin with our agenda where we'll have a brief overview of what we'll be covering in the get full course video let's start with the definition of git where we'll learn what git is and why should we learn it after which we will see how to install it now once this is done we will see some git commands with examples next we have git Basics we will then cover GitHub workflow and git Bash now it's time to Deep dive into the technical aspects of git we will start with the GitHub repository now once this is done we will then understand gitlab cicd pipeline after which we will then see what is git branching and stashing we can then see some of the Core Concepts in get like git merge and get rebates we will then compare git merge to get freebies now after all this we will then head over to Jenkins State integration after this we will understand what is webworks in Jenkins followed by kit Ops we truly hope that this session assists you in getting jobs in the industry in order to accomplish so we will look at how a career with Git works by seeing some essential get interview questions with answers so stick till the end now let's begin with our first topic what is kit foreign [Music] so to understand what is Version Control System we need to understand first why we need a version control system so we'll see why do we exactly need a version control system so for that let's take a scenario where there are three developers working remotely on a web application or a mobile application now for simplicity's sake let's just assume that it is a streaming application and one of them is working on a streaming page let's call them developer one developer 2 is working on a user information page and developer 3 is creating the payment portal now all three of them are done with their respective Pages at 10 o'clock 11 o'clock and 12 o'clock respectively now thing is all three developers are working in isolation there may be their own changes there may be changes in somebody's else's page they're all kind of adding some new files or modifying older files changing the source code or something like that throughout the course of this project but how exactly are they going to collaborate considering that they are working remotely the solution to this is a version control system with this system I'll tell you what happens at 10 o'clock developer 1 uploads all the files regarding the streaming page with the Version Control System this modification is recorded and updated to one Central directory or folder so every time you're modifying an older file or adding a new file it creates a snapshot of the latest version or the latest update of the changes that you've made or all the files that you've uploaded so the snapshot of your update at 10 o'clock is saved and then when developer 2 adds their user info page this modification is also saved as a snapshot now there are two snapshots saved and finally the payment portal page is added and this is the last modification done at 12 o'clock and this is the most recent snapshot saved along with other snapshots of other updates and modifications done throughout the course of this project every change in your project a snapshot is created and your entire project is saved that way and these snapshots are actually known as different versions which are basically the state of your project at a particular time or at the current time it means that it will contain the kind of files your project is storing at one particular time and what kind of changes you have made so far between the previous version and this particular version and this is exactly how a version control system works so Version Control System basically is a system that records changes to a file or a set of files over time so that you can record specific versions later these versions are recorded in a repository and they can be called any time from these repositories during the course of your project so Version Control Systems essentially are of three types now the local version control system is one of the simplest forms of VCS and has a database that keeps all the changes of the files under revision control so all the files are saved by this one user and they manage all of the files but it's actually really hard to maintain the changes of the file and you can accidentally replace one or the other file that you need it also needs something known as RCS or revision control system which keeps patch sets or the differences between updates in a special format on your disk all of this your local Version Control Systems maintains all the track of all the files within your local system as a user you can track specifically our versions later and it basically works as an independent Standalone system for an application so your applications like spreadsheets and word processors have this control mechanism so that's one type apart from this you also have your centralized version control system which basically uses a central server to store all the files and enables team collaboration so it's not one local system but multiple systems which work on a single repository to which users can directly access as a central server so the repository is a central server that could be local or remote which is directly connected to each of the programmers workstation and the Third Kind of VCS is a distributed version control system now these systems do not necessarily rely on a central server to store all the versions of a project file in a distributed Version Control System every contributor has a local copy or a clone of the main repository so everyone maintains their own local repository which contains all the files and the metadata present in the main repository and they can push or come commit or update the main repository if and when required now we are going to cover more on the latter two Version Control Systems further in the session so now let's try and understand in depth what's the difference between a centralized version control system and a distributed version control system as I had mentioned before in a centralized Version Control System each programmer working on a branch on a project has absolute access to the central server so the centralized version control system uses a central server to store all the files and everybody on the team can directly access the central server as it is one single repository so if you have three workstations workstation 1 workstation 2 workstation 3 all of them can directly commit to the repository and get updates from the repository which is your central server the repository here indicates a server that could be local or remote directly connected to each programmer's workstation every programmer can extract or update their workstations with the data present in the report repository or can make changes or updates or commit in the Repository and every operation is performed directly on this repository even though this seems pretty convenient when we are just talking about three people to maintain a single repository like this has some major drawbacks one of them is that it's not locally available meaning every change that you have to make you will have to be connected to a network to perform any action also in any case the central server getting crashed or corrupted will result in losing the entire data of the project also another small thing which is revertible but is if one person accidentally makes some unwanted updates instead of his or her local system they will be making that changes directly in the central server so recovering that part back will be again a time consuming process this is where distributed Version Control Systems come to the rescue now these systems do not necessarily rely on a central server to store all the versions of a project file in the distributed Version Control System each and every contributor has a local copy or a local workstation clone of the main repository that is everybody maintains a local repository of their own which contains all the files and metadata present in the main repository you will understand it better if you take a look at the diagram as you can see every programmer maintains a local repository or a local copy on its own which is actually the copy or clone of the central repository on their local hard drive they can commit and update their local repository without any interference from one another and then they can update their local repositories with new data from the central server by by an operation called pull once they are done with their bit of the code they can affect the changes of the main repository by an operation called push from their local Repository now this system or this act of cloning an entire repository to your workstation and making all the changes on a local repository gives you a couple of advantages over a centralized Version Control System first of all all the operations except push and pull are very fast because the tool only needs access to the hard drive and not a remote server hence you do not always need to be connected via a network connection or you always do not need an internet connection committing new change sets can be done locally without manipulating the data on the main repository once you have a group of change sets ready you can push them all at once so you complete your set of code on your local system and then you push all the files once and for all into the main Repository third since every contributor has a full copy of the project repository they can share changes with one another on wanting to get some feedback before affecting the changes in the main repository so this enhances the essence of collaboration amongst a development team and finally if the server gets crashed at any point in time the loss data can be easily recovered from one of the contributors local Repository and that is why distributed version control system has been picking up popularity over the past decade so why Version Control is important first of all it helps collaboration it allows remote development shared workspace and real-time updates all versions of your code are preserved hence it helps you manage versions of the same code easy rollback from current version suppose a part of your project has been headed to a wrong direction you can easily roll back from the current version to the last version which was stable now because you can reverse faulty updates you can save time and hence it reduces downtime of your project development and finally it improves visibility you can analyze and compare different versions and that gives you like a 50 foot top view of your entire project which just accelerates your product delivery so now that you have a bare sense of what is Version Control and why do you need Version Control let's understand one of the most popular version control systems that exist today and that is git so git is a distributed Version Control tool that supports distributed non-linear workflows by providing data Assurance from developing quality software so basically what it does is that it lets you and your team of developers work together on the same project remotely from anywhere across the world your team members can work efficiently on files and easily merge their changes into one source without the fear of losing or deleting anything of importance due to the easy rollback feature it is primarily used to manage a project comprising of a set of code or text files that you may want to change from time to time now git is an integral part of devops devops as most of you might have the idea of is the practice of bringing agility to the process of development and operations a couple years ago it was this entirely revolutionary ideology with swept the organizations worldwide boosting project life cycles and in turn increasing profits devops promoted communication between development engineers and operations participating together in the entire life cycle from design through development process to production support now in the entire life cycle of devops starting from planning of the projects to its deployment and monitoring git plays a vital role when it comes to managing the code that collaborators contribute to the shared repository this code is extracted for performing continuous integration to create a build and test it on the test server and eventually deploy it to production tools like git enable communication between the development and operation in Steam when you are developing a large project with a huge number of collaborators it is extremely important to have communication between the collaborators between the developers while making changes in the project comment messages in git play a very important role in this particular collaboration or communication amongst the team the bits and pieces that we deploy or update lies in this version control system such as git to succeed in devops you need to have all the communication in Version Control hence git plays an extremely vital role in succeeding at devops and due to this very reason git has earned way more popularity compared to other version control tools available in the market such as Apache subversion concurrent version systems and Mercurial if you compare the interest of git by time with other Version Control Systems you shall realize that larger companies products are generally developed by developers using git all around the globe and some famous names out of them are Facebook Yahoo Zynga quora Twitter eBay Salesforce Microsoft and many many more now lately all of Microsoft's new development work has been in git features Microsoft migrating.net and many of its open source projects on GitHub which are managed by git one of such projects is the light GBM it's a fast distributed high performance gradient boosting framework based on the decision tree algorithms which is used for ranking classification and many other machine learning tasks here git plays an important role in managing this distributed version of light GBM by providing speed and accuracy so basically to enable Version Control git is your go to solution it's fast and suitable for handling massive code bases scattered across multiple developers which makes it the most popular tool used today now that you know about git a terminology we'll be using a lot while talking about git and GitHub is a repository now repository or repo as its most commonly known as is a directory or a storage space where your projects can basically live it can be local to a folder or your computer or it can be a stored space in another online host such as your GitHub and in this particular space in this particular directory you can keep your code files text files images you name it all of it inside a repository through the course of this we shall also be talking about something known as GitHub which is nothing but a central repository the kind that we spoke about when we discussed centralized versus distributed Version Control Systems there's a central repository and that is where all of your code will live you have your local repository where you'll make the changes and there you have the central repository to which you will push all of the changes yeah and the central repository is something that all of the developers involved in this particular project in a certain project have access to all right moving on let's discuss a few git features which make it so popular amongst organizations as well as individuals first of all it's economical it's free and open source git is released under GPS general public licenses open source license so you don't need to purchase Git it is absolutely free and since it's open source you can modify the source code as per your requirement second is its speed now since you do not have to connect to any network for performing all of the operations it completes all the tasks really fast performance tests done by Mozilla showed it was an order of magnitude faster than other Version Control Systems fetching version history from locally sold repository can be 100 times faster than fetching it from the remote server so the core part of git is written in C which avoids runtime overheads associated with other high-level languages which makes it extremely fast compared to other Version Control Systems next is that git supports non-linear development it supports rapid branching and merging and includes specific tools for visualization and navigation of a non-linear development history a core assumption in git is that a change will be merged more often than it's written as it is passed on various reviewers hence branches in git are very very lightweight and is only a reference to a single Comet with a parental comets the full branch structure can be constructed next let's talk about the robustness nearly every single task in git is undoable git gives each developer a local copy of the entire development history and the changes copied from one repository to another these changes are imported as additional development branches and can be merged and deleted and recovered the same way as a locally developed Branch next is the snapshots which are recorded changes made to a file rather than the file itself followed by which you have integrity which means no changes can be made without git recording it since every contributor has their own local repository on the events of a system crash the loss data can be recovered from any of the local repositories you will always have a backup of all of your files and none of the changes made to the central repository will go unlocked by git git uses the sha1 or the secure hash function to name and identify objects within its repository and every file every comment is check summed and retrieved by its checksum at the time of the checkout the git history is stored in such a way that the ID of a particular version a commit in gets terms depends upon the complete development history leading up to that Comet once it's published it's not possible to change the old versions without it being recorded then it's a distributed system which means every user has their own copy of their repository and the data is stored locally git gives each developer a local copy of the entire development history and the changes are copied from one such repository to another these changes are imported as additional development branches and can be merged in the same way as a locally developed branch and finally it's easy branching now Branch management with Git is very simple it only takes a few seconds to create delete and merge branches feature branches provide an isolated environment for each change to your code base so when a developer wants to start working on something no matter how big or small they can create a fresh new branch which is not interfering with the main branch which ensures that the master branch of the main branch always contains production quality code so any little experimentation that you want to do or little things that you want to try out can always be on a separate feature Branch instead of the changes made to your master Branch because ultimately your master Branch should contain your publishable product so now that you know the basic features of git let's try and understand what the basic workflow of git is or how does git work so the basic overview of how git Works goes like this you basically create a repository or a project with a git hosting tool like git or bitbucket you copy or clone the repository to your own local machine or your working directory you add a file to your local repository and commit the changes which basically means you save the changes then you push the changes to your master Branch then you make changes to your file and commit then you pull the changes to your local machine you create a branch or a version make a change commit the change same process open a pull request and merge your branch to the master Branch now this is a little complicated listening to it like this but once we get on to our demonstration I think things will be way more clear you can still take a good look at this diagram but if you don't get it don't worry I will be explaining these operations one by one when we get to the demonstration part of this git tutorial moving on let's get to the good part the Hands-On section starting with the installation and setup of git now there are two ways in which this goes first of all for Windows users you need to install git bash for Windows and for Linux users you'll have to start by updating the package index and then install git using the terminal so first of all for our Learners using Windows you'll have to log on to get scm.com downloads and then click on downloads for Windows button and then run the executable file and follow through till you finally install get Bash I'm not going to install it completely as I already have git bash downloaded but I'm still going to open the page to show you guys all right so the latest Source release is get 2.30.1 on the 8th of Feb and you can just click on this button the moment you click on this button it's going to start downloading it to you and once you have the executable file all you have to do is open it or run it in your own system right next for people using Linux this is an example considering you are using Ubuntu if you're using Centos a lot of the commands don't change but instead of Apt install you will be using yum install for sentos so for that now I'm going to open my terminal on a virtual machine so here I have running an Ubuntu machine using the oracle virtualbox so I'm gonna start by running an update all right this is going to take a while kindly be patient so here I have my Ubuntu running on a virtual machine so to install git on your Ubuntu machine you have to start by updating so this will take some time if you're going to use sudo of Apt update if you're using Centos you will be using yum instead of Apt let's scale that out and then we're going to install git and then you can look for the Git Version yeah all right now that we have our git installed let's go ahead and look at the operations and commands that we are going to take a look at today you have your repository setup which include the commands init clone config and Alias then you have your save changes operations which have your add commit diff and stash all of these commands we're going to go on and off and look at collectively mostly then we're going to look at the inspect operations your inspect repository operations of which the git status command is something we are also going to look at throughout this demonstration right from the beginning so apart from that you have your kit log git tag and get blame commands so you have your merge rebase command so let's move on to our first set of get operations first of all you have your git init command which basically creates a new empty yet repository now this can be used to convert an existing inversion project to a kit repository or initiate an absolute fresh git repository now most of the git commands are not available outside of the initialized repository so this is usually the first command that you will run in a new project that is if you're using git Bash so when I run git in it it re-initializes an existing git repository which I already have here now what this does is it re-initialized my existing git repository in this particular directory in this dot get directory yeah what git init does is that it creates an empty git repository or re-initializes an existing one like it did for me right now it basically creates a DOT get directory with subdirectories and template files and when you run the git init command in an existing repository it will not overwrite the things that are already there it'll rather pick up the newly added templates so that's the repository initialized you can go ahead and create some files in the directory or repository whatever you call it now that is about initialization now what about if there was an existing repository on git that you had to act upon that you had to make updates to that you had to add files to things like that that's where you use the git clone utility yeah now you have the git clone utility which you use to Target an existing repository and create a clone or copy of this particular repository on your local machine now this is one of the features provided to you by a distributed version control system as we had discussed before so this is a blank file called edureka rep with just the readme text file let me just go ahead and copy this and then I can just get clone and paste its https URL and as you can see it's cloning this into a Eureka wrap and now if I change directory to edit a wrap you can see the readme file is right there yeah so we're basically going to work off of this particular repository today at Eureka wrap yeah so now that we created a clone moving on we have in the git config command which basically is a convenience function that is used to set up your git configuration values on your Global or local project level this command is basically used to modify your configuration text file so if I typed get config globaluser.email and here I type so there I given my email ID as the global user email ID so if I ask for what the global user email ID is it will return my ID back to me yeah basically these configuration levels like your username and your user ID correspond to your dot get config text files now executing this basically will help you modify the configuration text file git uses this series of configuration files to determine non-default behavior that you may want yeah so the first place git looks for these values is in the system-wide configuration file which contains settings that are applied to every user on this system so basically if you pass the option to your git config it will read and write from this file specifically and the next place the git looks is the config slash git config file which is specific to each user now you can make git read or write to this file by passing your Global option which is what I did and the final command in the setup operations that we are going to look at is an alias now Alias as the name suggests is basically used to create shorter commands that map to longer commands they enable more efficient workflows when you obviously have to use lesser keystrokes to execute a command there are these lengthy commands which obviously kill a lot of your time so these aliases you can use to shorten those commands and these are also something that you will create via the git config command there isn't really a direct way or a direct command of creating aliases yeah this is just something I wanted to add in here along with the git config command like a very common Alias created is co for checkout or anything else EK for checkout so yeah this is something that you can do using the git config command just creating aliases moving on let's look at operations that you use to add changes and save changes to your git Repository now the first two commands here that we're going to look at are git add and git commit now this combination is basically used to create these snapshots that I was talking about initially in this session right so basically what you do is first you use the git add command to add a change in your current directory or your working directory and you add that to the staging area it tells git that you want to include a particular set of updates or changes in a particular file in the next comment then what you do is you move on to git commit after making the changes to your working tree then you use the git commit command which captures a snapshot of your Project's current state so basically you use add to update the index using the current content found in your working tree and then you basically prepare the content in the staging area for the next commit then you run the commit command to take that snapshot of your Project's current status now remember this is very important and you have to do it each time you must use the add command to add any new modified files to the index you can't directly commit anything without adding it to the stage area first now what I did was I quickly went ahead and added three files to my repository at Eureka rep so if I go into this repository you can see there are three files at Eureka file one file two file three now let's see if these files are in my index or not using the command get status now git status basically displays the state of the working directory and the staging area it will list all the modified files which are ready to be added to the local repository it lets you see which changes have been staged and which haven't which files are being tracked by get and not so if I typed get status you can see on your main branch you have three untracked files which are the three files that I just added and Eureka file one two and three these are not added to the index yet this means I cannot commit these changes unless I added them explicitly to the index so now we are going to add these three files this command will update the index using the current content which is found in your working tree as you can see in front of you and then it will prepare the content in the staging area for the next comment so either I can just get add and put in the directory name or I can just use git add with an extension of a which means all and this will add all of these files to the index which are in the directory but not updated in the index yet yeah now I've done that let me go ahead and use git status again and you can see all of these file names are written in green and you can see changes to be committed written here which means all of these changes are ready to be committed they are added to the index now these files are added to the index you are ready to commit them now as I had mentioned before we're going to commit them and committing refers to recording the snapshots of the repository at any given time so your committed snapshots will never change unless it's done explicitly so I'm going to clear this and we're going to come at this by typing git Comet and then adding a tag or a message called committing three files let's try this out as you can see three files change three insertions you can see our eduraco files one two three have been committed the git comment command has committed the changes in the three files in your local repository now if you want to commit a snapshot of all of the changes in your working directory at once you can always go with commit hyphen a now let me add a couple more files to my directory just to show you the difference between your files added to the index versus the ones that are not if I type LS again you can see there are two more files over here as you can see I have two other files I'm just going to add the edureka file 4 and not the file 5 and then I'm just gonna get commit commenting files and as you can see only one file changed only one insertion happened and that only happened because edureka file 5 is not added to the index and even if I use the extension a I cannot add edureka file 5 because that has not been added to your index now if I just go ahead and add adurika file 5 voila the change has occurred in our git Repository now if I typed git status there are no more files to add or commit our branch is ahead of the origin or main branch by three commits and you can use git push to publish your local commits now what is get push this is something we will cover later in this session Now understand that before you affect the changes made to the central repository you should always pull changes from the central repository to your local repository just to get the most updated version of your branch you'll get all the work of your collaborators that have been contributing in the central repository for that you use the pull command now as you can see there's nothing to commit and you're working very slim there are other commands like the git status command which you could use for similar purposes for example you have the git log command which only operates on committed history it basically will display to you the committed snapshots and will let you list the project history filtrate and search for specific changes so if you are typed git log it's going to show you all the comments that have happened since we started with this git file okay here you can see at the bottom your original main there is your initial commit right then our first comment where we committed three files then we committed the fourth file and finally when we committed file number five right these are all the comments including the initial commit the first one yeah along with the author and the date and time remember when I told you about everything is recorded when you're using git this is what I meant you will can always access who made comments at what time and what comments were made when you use a Version Control System such as kit now at a point like this I think it's crucial to mention uh one more command which is the git tag and it's used to basically capture a tag in history or a point in history that is used for a marked version release right so it's basically uh like a branch that doesn't change and after being created they have no further history of comments yeah so that is one and another one is git blame now the get blame function displays of the author's metadata attached to a specific committed line in a file it's used to examine specific points in a files history and get context as to who the last author was that modified that line so if I went back and typed get blame [Music] edureka file 5 dot txt it's going to show who the person is that is to blame who committed this particular file or made this particular change right it'll also if you paid attention give you the commit number as you can see this E9 d63ef0 comment number this also has this E9 d63ef0 which is the first few characters of this particular comment number yeah so now that you know how to check the status of the changes and see who made the changes it's time that you understand how you fetch changes from your report repository to a local repository and how you push comments from your local repository to your remote repository so here we're going to look at two commands called pull and push so first of all you have the git pull command which fetches changes from your remote repository to a local repository basically it merges Upstream changes in your local repository which is a common task in gitbase collaborations but at first you need to set your central repository as the origin using the command git remote add origin and I'm going to add the link to my central repository which is this and as it says the remote origin already exists now that your origin is set and now we're going to pull our main branch so I'm just gonna type git pull origin Main and it says we are already up to date now certain number of tutorials or documents that you might be following might even give you the command git pull origin master in which case you're working on the master Branch now to know which branch you're at you can just use a command git branch Levy yeah I'll tell you which branch are you working on yeah so yeah we are working on the main branch and we are already up to date with the branch since my local repository was already updated with files from the main branch this is the message of an up-to-date branch now you can also like use git pull origin and your whatever Branch name here I'm using Main that's a mistake on my part maybe I was trying to clear the screen all right so here even if I pull from the branch using git pull origin and the branch name to my local get repository you can see it's already up to date so now my local git repository is now all updated with the recent changes so now it's time to make the changes to your central repository by using the push command so we're going to use the push command this command transfers commits from your local repository to your remote repository and it is basically the opposite of your poll operations pooling will import commits to your local repositories whereas pushing will export commits to your remote repositories it's going to ask you for your username and password before it lets you push into your main branch there so I've put in the username and password for my GitHub account and with that this has pushed the changes from my local repository to the remote repository along with all the necessary commits and internal objects now this has created a local branch in your destination repository the use of git push is to publish your local changes to a central depository after you've accumulated several local comments and are ready to share them with the rest of the team you can then push them to your central repository by using the get push command now the files which have already been committed previously in the comment section and they were all push ready you will use git push origin Master to reflect these files in the master branch of your Repository all right so let's go ahead to our repository and see if changes have been made and yes you can see all of our files on our GitHub repository you have when you wake up file one two three four and five all the five files that we had created on our local repository yeah you have all these five files and the readme file here here also you have the readme file and all the five files that we had created now at this point in this git tutorial I hope you have understood the basic commands of git you have pulling pushing adding committing things like that now let's take a step further and understand the three basic commands of parallel development here I'm going to be talking about branching merging and rebasing so first of all let's talk about merging now merging is a way to combine the work of different branches together this will basically allow you to Branch off develop a new feature and then combine it back in as you can see in the diagram it shows you two basically different branches new branch and master now when we merge the work of the new Branch into the master it creates a new Comet which contains all the work of the master and New Branch now if we merge the two branches with the merge command as I had mentioned before git allows you for easy branching which means you have parallel branches with your master branch that help you carry on your individual work while not interrupting your main product which is your master Branch or your main branch so branches in git are nothing but pointers to specific comments yeah so git generally prefers to keep its branches as lightweight as possible now there are basically two kinds of branches we are local and remote tracking branches a local branch is just not the path of your working tree on the other hand the remote tracking branches have special purposes some of them are linking your work from your local repository to your central repository and automatically detecting which remote branches to get changes from when you do a git pull so you can check what your local branch is by using get branch so you know you are at your main branch and the one thing you should understand one thing is like a main Mantra of people who use git are Branch early and Branch often yes so to create a new Branch you're going to use a command get branch and your branch name and this case I'm just going to use a branch name at Eureka images all right and here you can see this diagram shows the workflow of a new branch that is created when we create a new Branch it originates from the master Branch itself so since there is no storage or memory overhead with making many branches it's usually easier to logically divide your work up than having big chunky branches hence the branch often part now let's see how to commit using branches now branching includes the work of a particular commit along with all parent comments right so as you see the new branch has detached itself from the master or the main branch and hence it'll create a different path so we are going to get check out the branch name which in our case is edureka images and then we are going to get comment so you have on track files and Eureka images and nothing added so you made that branch now merging is a way to combine the work of different branches together so basically what this does is now that we've branched off to something known as edureka images you can go ahead add files to it develop a new feature and then combine it back into your main branch here you can see two different branches you have your new branch and your main branch and when we merge the work of a new Branch into the main branch it creates a new comment which contains all the work of the main branch and the new Branch so now if we merge this Branch as you can see it's already up to date it's important to know that the branch name here should be the branch that you want to merge into the branch that you are currently checking out so make sure that you are checked out of this destination Branch so let's just merge all the work of the branch at Eureka images into your main branch for that I will first check out my main branch and then merge at Eureka images with kit merge edureka images and as you can see all the data from the branch at Eureka images has merged into the main branch now notice that merging in Gate creates a special Comet that has two unique patterns now this is one way of merging into the main branch there's also another way of combining the work between two branches which is called rebasing now rebasing takes a set of comets copies them and stores them outside your repository the advantage of rebasing is that it can also be used to make linear sequence comets the comet log or the history of the repository stays clean if rebasing is done now our work from the new branch is placed right after master and we have this nice linear sequence of comments this command doesn't copy but moves all our work from the current Branch to the master or the main branch they look like they've been developed sequentially instead of having developed parallely so if I just did another branch called git Branch at Eureka images too and then maybe get checkout okay then we get Commit This and then I could just get rebase men and your current Branch will be up to date this command basically moves all of your work from your current Branch to your master branch and it'll basically look like it has been developed sequentially instead of having developed parallelly now apart from these there are certain operations that you ought to know firstly archiving your repository you can use this command it stores all of your files and data in a zip file rather than a DOT get directory this creates only a single snapshot omitting Version Control completely though this comes in handy when you want to send these files to a client for review who doesn't have git installed in their computers apart from this you can also bundle your repository which basically turns your entire repository into a single file this pushes the master Branch or the main branch to a remote Branch only contained in a file instead of a repository you could alternately change the repository clone the repo bundle create a copy and use git log but that is like five commands instead of one why not just use one command and finally stashing uncommitted changes when you want to undo adding a feature or any kind of added data temporarily we can always stash them temporarily you can use git status stash status and then you want to reapply the changes you stashed using git stash apply having said that let's move on to another very important topic in this git tutorial let's go through a brief introduction to SSH now what is ssh what is an SSH key now an SSH key is an access credential for secure shell Network protocol it's basically an authenticated and encrypted secure network protocol and is used for remote Communications between machines on an unsecured open network for remote file transfer Network management and remote operating system access so basically it's typically used to log into a remote machine and execute commands in it but this also supports tunneling forwarding TCP ports and X11 conditions it can transfer files using Associated SSH file transfer or secure copy protocols it provides you several alternative options for strong authentication and protects the communication security and integrity with very strong encryption it's a secure alternative to the non-protected login protocols and insecure file transfer methods such as FTP so basically how do you create SSH Keys you start by using the command SSH hyphen Keygen and then you'll be prompted to enter a file in which to save the key so home at Eureka then we're going to enter a pass phrase I'm just going to leave it empty again and you can see our identification has been saved in the file that we specified and we have something known as a key fingerprint and finally what we have to do is add the new SSH key to the SSH agent and then you will see identity added and that's it you have created an SSH key [Music] we will learn how to install git on Ascent OS machine but before we go ahead we need to install the software that git depends on these dependencies are all available in default Centos repository so let us proceed with that I'll type sudo yum group install development tools and here we go it is asking for password press y in the meantime let me tell you about the development tools it is a predefined bundle of software that can be installed at once instead of having to install each application separately the development tools will allow you to build and compile software from source code so it is done now let us clear our terminal and now I'm going to proceed with the second command and here we go is asking for password press y let us clear our terminal so now we are done with the prerequisites so we can proceed towards git installation to install git there is a command sudo yum install git but this command will install Git Version 1.7 by default but there are newer versions of git available so I'm going to install those newer versions for that I'll use W get command so let us first install wget tool sudo yum install wget and here we go so I'll press y foreign Let Me Clear My terminal now I'm going to use this W get command to download a specific version of Kit all right so I have to first copy the link of the version of git that I want to install so let me show you where I'll get that link I've already opened it in my browser you can see you can use this particular link and I will use git 2.7.2 this version I'm going to use you can select any version that you want all right so just right click copy the link location go back to the terminal and just paste it here we go so it is done now let me show you where it is downloaded in my machine here it is git 2.7.2 tar.gz let us go back to the terminal now now once the download is complete we will extract the file from the downloaded git tar file for that we will use tar command let me first clear the terminal now I'll type the command tar hyphen zxf get to tar.gz and here we go so now let me show you the extracted file here it is get 2.7.2 the extracted file now we'll go back to the terminal and let us change the directory to get so for that I'll type change directory get hyphen 2.7.2 and here we go since we are in the source folder now now we can begin the source build process all right so for that I'm going to use a cupboard called make configure Let Me Clear My terminal and now I'm going to type the second command and here we go this configure script is responsible for getting ready to build the software on your specific system it makes sure all the dependencies for the rest of the build and install process are available so let me clear my terminal now so now that the software is built and ready to run the files can be copied to their final destination for that I'll use a command sudo make install here we go this make install command will copy the build program and its libraries and documentation to the correct location foreign let me clear the terminal now to check the version of git that we have installed we'll use a command git hyphen hyphen version there we go so it is the correct version that is 2.7.2 now before we go ahead we need to submit some information about ourselves so that commit messages will be generated with the correct information attached we need to provide name and email address that we would like to have embedded it to our commits for that we will use the command that I'll type let me first clear it it is kit config hyphen hyphen global user.name and your name here we go for the email ID I'll type git config hyphen hyphen global user dot email and your email ID here we go now to confirm that these configurations are added successfully I'll use a command git called fake hyphen hyphen list so username with saurabh and email ID is saurabate edureka.com which is absolutely correct all right so now what we need to do is we need to generate a SSH key SSH is a secure protocol used as a primary means of connecting to Linux servers remotely all right so let me first clear my terminal now I'm going to type the command to generate the SSH key which is SSH hyphen Keygen hyphen T RSA hyphen b4096 hyphen C and your email address here we go enter file in which to save the key so if I just press enter it will go to the default location so let us do that enter passphrase so if I want it to be empty so I'll just press enter enter the same passphrase again so now we have generated the SSH key now there's a program called SSH agent that runs the duration of a local login session stores unencrypted keys in memory and communicates with SSH clients using a Unix domain socket so it is very important to ensure that this SSH agent is enabled so let us enable it foreign now we need to add this SSH key to the SSH agent so let's proceed with that here we go so we have done that successfully now we need to add this SSH key to our GitHub account all right so for that I'll use this cat command this cat command will actually read the key and it will display it on the terminal so let me show you foreign so this is the SSH key that I was talking about so now what we need to do is we need to just copy this SSH key and we need to go to the official GitHub website so let us Google GitHub I will go to their official website over here I need to sign in first so I'll use my login credentials foreign what you need to do is you need to go to settings over here click on settings and on the left hand side there's an option called SSH and gpg keys just click on it and you can see there's an option where my cursor is pointing new SSH key let us click on it and we need to add a title over here so you can type any uh title you want I'll just type edureka and over here I'll paste the key that I've copied from my terminal finally we need to add this SSH key so I'll just proceed with that let us see what happens now as you can see the key has been created but now what we need to do is we need to test this key for that I'll go back to my terminal let me clear it first now to test this SSH key we'll use a command SSH hyphen capital T get added rate github.com here we go press yes so now let us go back to the website and see what change has happened just refresh this link as you can see the color of this key has changed to Green that means we have successfully tested the SSH key now we'll look at some of the most commonly used operations performed on git that is push and pull operation let me first clear my terminal for that I'll first create a folder and I will name it as get hyphen repo you can name it anything that you want and I'll keep it empty I'll go back to my terminal and I'll change my directory to that git support here we go so now I have entered the git report directory now I need to initialize it first so for that I'll use a command git init so it has been initialized successfully now to allow GitHub to hold our files we need a command git remote add origin let me first clear my terminal now to allow GitHub to hold our files we need a command that I'll just type git remote add origin and the SSH link let me show you from where you'll get this SSH link first we need to create a repository so here's an option called new repository we'll go there will give a repository name I'll just name it as edureka hyphen01 and I'll initialize this repository with the readme and finally create a repository you can add a description as well if you want over here you can see that edureka01 repository has been created with a readme file in it the SSH link that I was talking about you can find it from here clone or download just click on it here is a link just copy go back to the terminal and just paste it here and here we go so now we'll perform the pull operation all right so when we have successfully performed the pull operation this read B file over here will be copied to our git repository the local git repository but I want to add this thing when you're doing it for the first time you need to always pull files from the GitHub account to your local git repository and then you can proceed towards pushing your files from git repository to the GitHub account I hope I'm clear so let us now perform the git pull operation so I'll type the command for it git pull origin master here we go now let us go to git repo and see whether the readme file is there or not as you can see we have successfully performed the pull operation the readme file is present over here now we need to perform the push operation for that I'll go back to the terminal and what I need to do is I need to create a file in this git support all right and uh I can just name it as edureka and I will write here welcome to edureka save it close it and go back to the terminal now over here we need to add this file that I've just created that is edureka so for that we have a command git add and the file name which is edureka in this case here we go so now what we need to do is we need to commit changes so for that I'll use the command get commit hyphen M and the message you want uh to display I'll just type first commit here we go so let me clear my terminal now we'll perform the push operation so when we are successfully perform the pull operation this edureka file will appear in the GitHub account which I have created over here so it will be present here so let us see if that happens or not so we'll type the command for it get push origin Master here we go so let us go to my GitHub account and check whether it has been added or not I'll refresh this link as you can see edureka file has been added over here and this is what I actually wrote welcome to edureka so now we have successfully performed push as well as pull operation [Music] let's focus on various kit commands so we'll start with Git init command now git init is basically to turn a directory into an mtk repository now the first thing that you need you need a local repository to work with for those of you who don't know what exactly local repository is it is basically a private copy of the whole repository of the whole shared repository that you have and users can perform many operations with this repository such as ADD file remove file rename file move file you can commit changes and you can do a lot of things with your local repository so the First Command that we are going to discuss is basically the git init command which will turn a directory into an empty git repository so for that I'll open my Virtual Machine to show you practically if you are facing any issues in installing git you can go ahead and refer my git installation video there also I have installed git incentivize version 6.5 so for now let me open my Virtual Machine and I'll show you there so guys this is my virtual machine where I've installed git if you want to see the version of git that you have installed just type in here get hyphen hyphen version and it is 2.7.2 in my case now let's go ahead and create the directory first so I'm going to name my directory as edureka hyphen Repository now I'm gonna move into this directory so I'll just type in here CD record so now I have a directory I want to convert it into a local git repository which is very easy all I have to do is type in git init and here we go so initialized empty git repository in home address so let's go back to our slides again and we'll see which command we are going to discuss next let's talk about git add now so git add basically adds all the files to the staging area for git now git doesn't track each and every modified file so whenever you do the commit operation git looks for the files present in the staging area only those files present in the staging area are considered for commit and not all the modified files so the first thing you need to do is put all the modified files all the changes that you have done into the staging area and then from staging area you can go ahead and make a comment right so the first thing is to add your files to the staging area which is pretty easy all I have to do is type in git add in the file name so let me just quickly open my Virtual Machine and show you that this is my virtual machine again guys and first let me just create a file here let the name of my file be uh at eureka.py yeah let me just go ahead and type something in this uh dot py file so I'll just type in here a equal to 10 a small code be equal to 20 and I'm going to print a plus b pretty basic save it and go ahead and close it right now what I need to do is add the changes that I've done into the staging area right so all I need to do is type in here get add and the name of the file that is edureka.py so I've successfully done that if I want to add all the files to the staging area then I can go ahead and type git add and a period right so this will add all the files that are there in my local repository to the staging area so this was all about git add let me just quickly open my slides and we'll see which is the next command we are going to discuss now we are going to see the git commit command so git commit basically records the changes made to the files in a local repository so you have all the modified files in the staging area so when you make a commit it'll basically record the changes that you have made to the files in that local repository and for easy reference each commit has a unique ID and it is a good practice to always give a commit message right so that helps you in understanding what change was done in this particular comment right so I'll just quickly open my Virtual Machine and I'll show you how you can commit changes to the local repository this is my virtual machine again guys so I'm just going to type in here get commit hyphen M and then commit message so I'll just type in here first comet right so I've done that successfully two files changed five insertions create mode one double zero six double four at arraycar dot py right so this is the log for it let me just clear the terminal and go back to my slides again let's talk about a git status now so git status Returns the current state of the repository git status will return the current working Branch if a file is in staging area but not committed it shows with Git status or if there are no changes it will return nothing to commit working directories clean right so let me just open my Virtual Machine again and I'll show you practically how this works all right so if I go ahead and type here get status so it says on Branch Master nothing to commit working directory clean so it gives me the name of my branch and what is there anything that we need to commit or something that is already there in the staging area but I have not committed that and the working directory is clean right now so whatever changes that I've made in my file are there in the staging area and from the staging area I've made a comment as well right so let me just do one thing make some changes in the file add it to the staging area but I won't commit it right so let's see what will be the status then so for that I'll create one more file let that be welcome.pui uh edit this using G edit you can use whatever editor you want I'll just type in here print welcome to edureka close the parenthesis save it and close it now I'm gonna add this file to the staging area so I'm just going to type in here git add I can go ahead and type a period as well that will add all the files or I can give the name of the file that is welcome.py now if I type git status let us see what will come so it says new file welcome.py changes to be committed right so these changes are present in the staging area but I have not committed these changes uh it gives me the name of my Branch as well so I hope you have understood what exactly git status is so I'll just quickly open my slides again and see which command we are going to discuss next let's talk about git config now now with Git there are many configurations and settings possible so git config is basically how to assign these settings now two important settings are username and user email address these values set what email address and name commits will be from on a local computer and it's very easy to do that let me just quickly open my VM and I'll show you that now there are two things either I can run the git config command globally or I can run the git config command on the current repository settings so let me show you how you can do it globally so I'll just type in here git config hyphen hyphen Global user dot name and the name of the user so let it be subham and now I can go ahead and add the email address as well so I just need to type in here user dot email and I'll type the email address and the parenthesis in the double quotes right so this is done and this was done globally now if I want to execute this on the current repository what I'll type in git config I won't use hyphen hyphen Global I will directly go ahead and type user dot name so let it be my name I say u r a b h and I'm gonna add my email address as well done guys it's that easy now let me quickly open my slides again and we'll see which command we are going to execute next so we've seen how git config Works let's discuss about git branching now now before I proceed let me tell you that there will be a separate tutorial video on git branching where we are going to discuss in detail about it here I'll just give you a quick introduction to branching so the first question is why do we need Branch right so branches are used to create another line of development and by default git has a master Branch so usually a branch is created to work on a new feature so if you're working on a web application you might want to work on the card service right so for that you'll create a new feature Branch or any name that you want to give to your branch and once the feature is completed it is merged back with the master branch and we delete the feature branch and every branch is referenced by head which points to the latest comment in the branch whenever you make a commit head is updated with the latest commit let me just quickly open my Virtual Machine and over there we're going to see how to create a branch how to delete a branch how to rename how to merge and how to check out into a different branch this is my virtual machine again guys and uh let me just tell you how you can see all the branches so just type in here get branch and uh and it will list all the branches that are already there so there's only one master Branch present right now so let me just quickly go ahead and create a branch see there are two ways to create a branch one way is to create a branch and then you can check into that Branch another is you just want to create it but you still want to be in your master Branch or your current working Branch so for that uh if you don't want to check in that Branch just type in here get branch and give a name to your branch so let that be feature right and if I go ahead and type git Branch now I can see that there are two branches master and feature right now I can go ahead and delete this Branch as well but let me just quickly uh move into this Branch first so I'll just type in here git checkout and the name of my branch that is featured and this will Point towards my feature Branch now I'm in my feature Branch right so let me just make some changes in the files that are there in my edureka repo so you can see that I have couple of files iteraker.py and welcome.py so let me just make some change in let it be at arrayca.py right so I'll just quickly type in here G edit again you can use whatever editor that you want edureka.py and I'll just add one more variable here let that be 30 and I'll print one more value that is C plus a plus b pretty basic save it and then go back so in my feature Branch I have made changes to my editoraker.py file right so what will be my next step is to add these changes add the modified file in the staging area so I'll just type in here get add and a period because I want all the changes that I've made to my files should be there in the staging area so git add and period will add all the files now I want to commit these changes so I'll just type in here git commit hyphen M and a message feature commit right said now I've done all the changes and I've added those changes to the staging area and then finally I've made a comment as well so it says four files change 10 insertions create mode welcome.py welcome.py let me just clear my terminal now so if I want to merge my feature Branch with the master Branch now first I need to check into my master Branch for that I'll type in here get check out master now it says switching to Branch master from feature now I'm in my master Branch so now I'm gonna type in here get merge feature and here we go so you can see that I've merged my feature Branch with that of the master Branch it's that easy guys let me clear my terminal now so what I'll do I'll quickly create one more branch and and I'll show you again uh how these things are happening because there might be some confusion still so I'll just show you again how to create a branch how to check into that Branch how to make some changes in your local repository add that to the staging area make a commit and then merge it with the master branch so now uh what I'm gonna do is I'm going to delete my feature Branch because I've told you earlier as well once I've merged all my changes to my master Branch there's no point in keeping my feature Branch as of now I delete that branch and there are a couple of options to do that the safest one is what I'm gonna tell you right so I'll just quickly uh type in here uh get Branch hyphen D and the name of your branch which in my case is feature so it has deleted the branch feature now there's one more way to delete a branch instead of hyphen D you can just type in here get Branch hyphen uppercase D and then the name of the branch but this is not the preferred option and it's not safe as well because if you have some unmerged changes then also it will delete the branch whereas if you type in here a lowercase D it will show you a error that will say that you have some unmerged changes right so always prefer a hyphen small d uh and then feature hyphen small D and then the name of the branch that you want to delete right so now I'm going to show you one more way to create a branch which is called the git checkout hyphen B and you can give the name to your branch right so uh probably I want to name my Branch again as a new let the name of my Branch be new so get check out hyphen B new so this will not only create a branch called new but it will also check into that Branch right so we have also checked switch to a new branch that is new and over here also if I want to make changes to my file I can go ahead and do that all I have to do is use any editor Let me uh edit say welcome dot py file welcome to edureka I forgot to close the quotation so that's the change I'm gonna do in this file right and then I'm gonna get add period now get commit I made a mistake there so I'll just type in here get comment hyphen m and uh let it be new the message all right so it is done now so guys this was all about git branching in this video I'll be coming up with a separate video on git Branch so you can stay posted by subscribing to our channel to get the notification now what I'm gonna do is I'm gonna show you how to connect to a remote repository so I have a remote repository the GitHub account I've created a repository there so if I want to connect to that repository what I need to do is I need to add that origin so I'll just type in here git remote add origin and the SSH link that I will just show you where you can find it so this is my GitHub account guys and this is my repository that is git commands if I want to copy the SSH link I can just go ahead copy this and paste it here so we have successfully added the origin now let me just clear my terminal so we have connected a local repository with the GitHub account so we have seen how branching Works in git let us move forward and we'll see how to work with remote repository so over here I've already told you how to add an origin right it's a git remote add origin and what we did we connected a local repository with a remote repository so The edureka Hyphen repo is my local repository and a remote repository I just showed you in my GitHub account so we have already done this git remote algorithm so now we're gonna see how to clone a remote repository so to create a local working copy of an existing remote repository we'll use git clone to copy and download the repository to a local computer throwning is the equivalent of git init when working with a remote repository git will create a directory locally with all the files in repository history so I'll just open my Virtual Machine and I'll quickly show you how you can do that all right so what I'm gonna do is I'm first gonna create one more directory so let that be mkdir and uh the name of the directory Let It Be git hyphen repo right and let's move into this git hyphen Repository so the first thing I'm going to do is git clone git clone and the SSH link so SSH link I've already shown you where you can find it in your GitHub account just type in here get clone and the remote repository URL the SSH link that I was talking about and let me show you how you can do that and here we go so it says cloning into git commands so let me see what are the files that are there now so it says git commands let me go to this git commands so here we have ederek and readme and here also you can notice that we have edureka and readme so I've successfully done that let me clear my terminal and now uh I can go ahead and pull whatever changes I made to the file that is there in my GitHub account so let me just show you how to do that suppose if I have a file edureka and let me just make some changes here I'll just type in here my name is saurabh so let it be like this so let's come and change this so yeah now it'll be reflected in my Repository now what I want is I want all the changes that have been made in my remote repository in my local machine so for that I'll just type in here git pull origin master and here we go so it says it has successfully done that that means we have pulled all the files that are there in the report repository so if I check so I have here edereka and readme.md files so if I go ahead and type in G edit edureka let's see or or right so I can see that the changes have been reflected my name is saurabh which was something new that I added to my file right so this is all about the pull operation now let us see how you can push changes to the remote repository right so if I go ahead and make some changes or if I create a file let's say I create a file touch get Dot py and let that be get one dot py right so if I make some changes to this particular file I'll write here print I love git save it close it right so now before we push to the remote repository we need to add these changes to the staging area we need to make a commit and then only we can push it right so first thing add the file name so I'll just type in here get add I can go ahead and type here if period that will add all the changes made to the files in the staging area all the files in the staging area basically modified files or I can type the name of my file which in my case is git1.py so I'll just type in here get add get1.py and now I'm going to commit the changes so I'll just type in here git commit hyphen m give a message so I'll just type in here remote and it has done successfully so now I can go ahead and push the changes to my remote repository so I'll just type in here get push origin master and here we go so it says it is done successfully let us go back to our GitHub account and we'll see whether those changes are reflected there and or not so I'll just go ahead and run this basically reload it so you can see that get1.py file is added here right so let me just quickly go to the slides again and we'll see what all topics we have already covered so we have seen how to perform git clone we have seen how to pull changes from the remote repository to the local computer we have seen how to push the local comments to the remote repository now let's talk about few Advanced git commands focus on git stash git log gets rebase and get revert so I'll quickly open my Virtual Machine and I will explain you there only so guys let's discuss about git stash first so to save changes made when they are not in a state to commit them to a repository you use gitstash this will store the work and give a clean working directory if I have to give you an example imagine when you're working on a new feature that's not complete but an urgent bug needs attention so that's when you can use get stash let me just quickly show you how you can use it so the first thing I'm going to do is create a new file so let the name of my file be stash Dot py and I'm gonna make some changes to the stash.py I'll just type in here print stash is cool save it close it and yeah now what I need to do is add this to the staging area so I'll just type in here get add and now let's see the git status so my git status says that we have new file which are there in the staging area that is stash.py right changes to be committed so these are the changes that I need to commit So currently it is pretty dirty so what I can do is I can put all the uncommitted changes to a stash let me show you okay and do that get stash hyphen U and here we go now go ahead and type get status nothing to do working directory clean so it has converted my dirty directory to a pretty clean one right so with the help of git stash right now the modification stashed away by this command can be listed with Git stash list so I'll just type in here get stash list here we go and if you want to inspect it so you can just go ahead and type git Dash and show so you can inspect it here right Let Me Clear My terminal now so now I'm done I've fixed my bug and now I'm ready to you know work on what exactly I was doing before fixing that bug right so what I can do is I just want to type in here get stash apply and here we go and now if I type git status you can see that I again got the dirty directory pack so guys we have seen how gitstash works now what I'm going to do I'm going to show you how a git log and git reward works right so uh for that I'll quickly create a new repository so let me do that I'll just type in here mkdir git hyphen log so let that be the name of my directory and I'll go into that directory yeah so now I'm going to initialize it so I'm just going to type in here get init it has been done now I will uh create few files here uh let that be edureka1 Dot py and I'll just type in here print Master new technologies at EDU daker all right save it and close it now I'm going to add it here git add and then finally committed hyphen m just give a message and it is done now so what I did I created a directory initialized it then what I did I made a file inside that in that file I added that to my staging area that file has been added to my staging area and then finally I made a commit right so till now there is no problem now if I type here get log let me show you what comes so you can see that when I type git log there's a commit hash right there is a commit that has been made by authorship on this particular date and day right so this is what basically git log is it shows the chronological comment history for a repository this helps you give context in history for a repository and it is available immediately on a recently cloned repository to see the history as well now I can provide parameters here as well for example I can type in here get log hyphen before and give a date here right similarly I can tell the git lock to show me the comments based on the author right so if I type in here get log hyphen hyphen author and the name of the author then it will show the logs based on the commit made by the author right similarly if I type in here hyphen hyphen before right and give a date so it will give me according to the date as well so this is how git log Works guys so now what I'm going to show you is how to revert to the previous commit right so for that let me just make some changes to my file again so the name of my file is iteraker1.py so I'll just type in here G edit edureka1.py and I'll type in here one more print statement that says don't just simply learn it Master it save it close it now I'm gonna add it to my staging area and finally I'm gonna commit it hyphen m last commit all right so this is done now now what I have to do is suppose I have made some changes I'm gonna go back to the previous change right so I've made some change in my code I've done the commit as well but I want to go back to the previous comment right so for that what we use we use git revert so let me show you how you can do that so in order to go back to the previous comment what I have to do is just type in here get log hyphen hyphen one line this will give me one line so this was my last commit so I want to go back right so for that I'm just going to type in here get revert and the hash comment hash and here we go so it says that revert last commit so it has already done that now if I go ahead and check my EDU recap.1.py file so it only says Master new technologies at edureka so this is how you can even perform the revert operation just by using in the uh commit hash so with that you can go ahead and revert back to the previous commit so I hope this is clear now let me clear my terminal so now what I can do is I can go ahead and revert to the last comment as well instead of just typing the commit hash if I just type in here get reward head and if I quit so it says that I rolled back to the previous version of my file so if I go ahead and click on LS command and if I type in here cat editor1.py so I've gone back don't just simply learn it Master it so my last comment was basically revert operation right so whatever file changes that have been done after get revert will be reflected as a commit itself right so I hope you're getting my point so what I did first I created an empty repository then in that I created a file editoraker one dot py made a couple of changes made two comments then I used get revert with the hash commit to go back to the previous commit right so with that I got only Master new technologies Etc this one I didn't get at that time then what I did I showed you get revert head which will basically take the last comment right it will reverse the last comment and the last comment was nothing but the revert operation that happened that actually made my file at rega1.py to go back to the previous version so that was my last comment right so because of that it has revert back to the last comment this is why you can see that edrica1.py file has both Master new technologies at the direct and don't just simply learn it Master it right so I hope I'm clear with Git log and git reward it's very easy guys there's not a lot of things to understand here it's very basic so let's talk about rebase now so basically rebase is again one more way of combining the work between different branches so what rebasing does it'll take a set of comments copy them and store them outside your repository the advantage of rebasing is that it can be used to make linear sequence of comments All right so the commit log or history of the repository stays clean if rebasing is done right so let me just show you how it is done if I just type in here git rebase Master let me just go ahead and do that git rebase master so the current Master is up to date that's what the message pops up so basically this command will move all our work from current Branch to the master Branch they look like as if they are developed sequentially but they are developed parallely all right so let me just give you a better example of this so I'll just create a branch here git branch say at Eureka 0 1 0 is the name of my branch and uh yeah so if I want to go to this branch check out edureka010 yeah I went to that branch and if I make changes to and eureka1.py I'm going to remove this print statement save it close it clean my terminal and I'm gonna add it get add period and get commit hyphen m rebase all right so this is done now and now what I can do is I can go ahead and type in here get rebase master so it says that current Branch 0 1 0 is up to date so this is how you can perform rebasing so let me quickly go back to my slides so we have talked about git stash we talked about git log git rebase and git revert [Music] the need for GitHub it is extremely important for software developers to work on a web-based platform to share their projects and collaborate with other developers this platform must be a version control system that is it must enable multiple people to simultaneously work on a single project each person edits his or her own copy of the files and chooses when to share those changes with the rest of the team this application must also be capable of Hosting millions of programmers and hobbyists that download and evaluate each other's work GitHub is one such platform of choice for developers that can host multiple programmers and review their code GitHub has several competitors for instance git lab gitlab is an open source web interface and Source control platform based on git whereas Microsoft team Foundation server is an Enterprise grade server for teams to share code track work and ship software for any language all in a single package bitbucket on the other hand stores all of your git and Mercurial source code in one place with unlimited private repositories so what really makes GitHub so powerful and popular among Developers GitHub is an open source platform and the community is really what fuels it moreover GitHub is the platform of choice for developers from various large corporations too Microsoft is the number one contributor to the system but there are also Google sap Airbnb IBM PayPal and many others exposure and insight that you can get on GitHub are simply unmatched by any other platform here you can discover code written by others learn from it and even use it for your own projects versions control on GitHub works very much like Microsoft Office or Google drive it simply tracks all the changes made to your code and who makes them you can always review the detailed change log that neatly hosts all of the relevant information using GitHub eliminates the need for complex corporate security solution because everything is on cloud the platforms protects code branches verifies commit signing and controls access now that we know why we need GitHub let us understand what is GitHub GitHub is a git repository hosting service that provides a web-based graphical interface with many features a repository is usually used to organize a single project repositories can contain folders files images videos spreadsheets anything your project needs let's say for example a team wants to work on a particular project here they can simultaneously write and update the code to a central repository which is present on GitHub so GitHub is a highly used software that is typically used for Version Control it is helpful when more than just see one person is working on a project for example a software development team wants to build a website and everyone has to update their codes simultaneously while working on this project in this case GitHub helps them to build a centralized repository where everyone can upload edit and manage the code files most software projects have a bug tracker of some kind github's tracker is called issues and has its very own section in every repository issues basically are a great way to keep track of tasks enhancements and bugs for your project moving on people often get confused between the terms get and GitHub now let me clearly explain the difference between them git is simply a version control system that lets you manage and track changes within your project whereas GitHub is a cloud-based service that lets you manage git repositories so basically git is the tool and GitHub is the service now that we know the difference between git and GitHub let us move on and understand how these two work hand in hand we already know that git is a Version Control tool that will allow you to perform all kinds of operations to fetch data from the central server or push data to it whereas GitHub is a code hosting platform for Version Control collaboration GitHub is basically a company that allows you to host a central repository in a remote server now without any further Ado let's get started with the demonstration on how to use GitHub so for this demonstration we're working on the website version of GitHub this another version of GitHub that is the desktop version which you can download it to your personal computer so we're simply going to search for GitHub in our search engine the first link will lead you to the official website of GitHub so I'm going to click on that so this will redirect me to the main home page of GitHub as you can see there is a search GitHub option there are also two buttons that says sign in and sign up if you're new to GitHub you can simply enter in your credentials that is a username email password and sign up for GitHub but if you already have an account like I do I'm simply going to click on the sign in button and it'll redirect me to a page where I have to enter the credentials that is my email address and password I'm going to do that now and I'm going to click on the sign in button now this is the main page of my account as you can see I have no repositories it's all new it's all fresh but if you're not new to GitHub you can view all of your repositories on the left hand corner now before we move on I'm going to explain you all the features that are present within GitHub so you can see a search bar here so the search bar will allow you to look for profiles certain keywords look for different kinds of projects that are available on GitHub all of those can be done using this bar here and you can see four options next to the bar that says pull request issues Marketplace explore pull requests will learn later on in this session but the issues in Marketplace we won't be discussing in this video for now the explore button on the other hand is an extremely important and interesting button so once I click on that it'll redirect me to a page with some activities that are going on around in GitHub you can see here the trending repositories they're tendering developers basically this is a fee that will allow you to interact with developers and other people collaborators from all around the world basically in Instagram too you have an explore button which will allow you to interact with different people from all around the world so the same concept is implied in the GitHub explore button too so you can explore top effects you can explore tending repositories developers basically it's an interaction with other people from different parts of the world so I hope that's clear now the most important part of the session are the three buttons that are available in the right hand corner of the navigation bar so you can see there's a bell icon there's a plus icon there's a pixelated icon on the right hand corner so the Bell icon allows you to read notifications of your activities that occur in GitHub so that's what it really is you can see the inbox will allow you to view all of the notifications you can also view the Android notifications by clicking on this unread button as of now I don't have any notifications so there's nothing available you can also group these notifications by the date or repository by clicking on this group by button here you can also view your save notifications by clicking on here and the done button on the other hand will let you mark all of your notifications that you're done with your previous notifications so these are the three important buttons you have to know in this Bell icon and the filters are not necessary as of now so I'm not going to discuss that this button on the other hand will allow you to manage your notification settings and your subscriptions too so that's all for this Bell icon the next important button is this plus icon as you can see there are five drop down options that appear here the first one being new repository followed by import repository new just new organization new project so new repository we've already discussed previously in this session a repository is a place where you create your files for your project it's basically a storage space right so you repository can directly interact with your git right so the new repository option will allow you to make files a repository to your GitHub account right the git on the other hand the tool that which we use to make local repositories in our personal computer can be directly pushed on the local repositories can directly be pushed onto your GitHub account so that's what the new repository pattern allows you to do so but the new project on the other hand is a place to track issues features and other tasks that are related to the code within the repository you can also connect with the devops build and deploy process assign people to tasks and so on by using this button that is the new project button so the difference between the new repository button and the new project button is that projects in GitHub are only a part of GitHub but not git but the new repository option is a part of GitHub and git so that's the main difference between neuroposity and new project I hope that's clear so the next button will drop me down some interactions that I can make with my profile so if I click on this your profile option it will redirect me to a page where I can edit my profile I can really create my identity using this page so here if I click the edit profile I can add a bio about myself I can add the company in which I'm working in the location at where I am the website Twitter username Etc all of that I can add here all of the information about myself I can also view the repositories I'm working on currently or the repositories I've worked in the past projects that I'm working on the packages and the entire contributions I've been making on GitHub from the last year so basically it allows me to build an identity or it'll help me build my profile on GitHub so I hope that's clear now if I click on this button and if I want to sign out from a profile I can simply scroll down and click on the sign out button here and this will sign me out of my account so that's all for getting started with GitHub these are the basics on what GitHub is and what each of the button and options really do now if I want to move back to the main page of my GitHub profile I can simply click on this octocad that's github's logo so I'm just going to click on this octocat logo and here I'm back to my main page now before we move on and work on the different operations and options within GitHub and learn different things about GitHub I'm going to give you a brief overview on how to download the desktop version of GitHub so I'm simply going to search for GitHub desktop on my search engine and I'm going to click on the first link that's available on this page now I can simply click on this button that says download for Windows 64-bit that's compatible to my current version of my personal computer if you have a Mac you can simply click on the Mac version and download it to your desktop but as I've already mentioned previously that we're going to work on the website version so I'm going to Simply switch back to this now let's quickly move on to the next part of the session create a repository so firstly let us understand what a repository is it is simply a storage space for the correct project that you're working on GitHub is a very popular Central repository that allows you to share your files whereas git allows you to create local repositories that are present on the system you are working on so you can basically push your local repository into GitHub and share it with other collaborators via the central one now that we know what a repository is and how it works let's go on to the demonstration part and create a first Repository so you can do this in two ways either you can click on your create repository button that is present on the left side or you can as I've already mentioned in the previous part of the session you can click on to this plus icon and you can click on the new repository option so this will redirect you to a page that says create a new repository you can add your repository name I'm going to name my repository as edureka and it's available all of your repository names must be unique from one another to identify them easily you can also add a description which is optional I'm just going to add the description this is my first Repository and a description allows people or other collaborators to understand what your repository is all about but as a good developer or a good programmer you would definitely want to add a description and give an overview of what your repository is all about there are two options now available that says private or public now you can choose your repository to either be public or private so the private One lets you decide who can access your profile whereas the public One lets anyone View and access your repository but you can choose who can commit to it that's the difference between public and private repository I'm going to let my repository be public as of now now if you scroll down you can see that you can initialize your repository with three options the first one being add a readme file the second one being add a git ignore file you can always choose a add a readme text file to your project which often contains information about the project and other necessary details the user must be aware of when he or she is accessing that particular project now I want a readme file for my repository so I'm going to click on this button here that's going to check it the next option is add a DOT get ignore file so this file will let you ignore a list of files when the user is pushing files to GitHub that's what this option really does but I'm going to let this be unchecked for now for your repository to truly be open source you will need to license it so others are free to use change and distribute the software you can simply click on choose a license option and pick your the required license for your project there are several licenses like MIT GPL Apache License 2.0 BSD Etc but for this repository we don't really need a license so I'm going to untick this too and now you can see there's a piece of information that says this will set master as the default Branch but I'm going to ignore this for now I'm going to explain about branches later on in the session so this is all you have to do to create your first new repository you add a name you choose a description you add an optional description you let your repository be either public or private and you initialize a repository with either of these three options and I'm simply going to click on my create robustry option now this will redirect me to a page with all the information and the files that are currently present in my repository you can see here my repository name is present here with the optional description that I gave and the number of files currently we have only just one file that's the readme text file and that's present here so this is all we have congratulations you just created your first repository now you can see there are some options that says issues pull requests actions projects Wiki security Etc we don't have to really talk about all of these right now we will just learn about one option that says code here so this is really important if you click on this button you can see that there's a link that is available here and https link so if you copy this link and paste it on your kit terminal that's present on your computer you can download this entire project directly to your local system so that's what the link is for I hope that's clear and the next option that says open with GitHub desktop will allow you to open this entire repository in your GitHub desktop version and you can also the last option that says download zip will allow you to download this entire repository in the form of zip files so all of your project files will be within that zip file so that's all you have to really know about your repository and and I'm going to click on the readme text file that's available it will take me to another page with some extra information about that file you can see currently we have two lines and the memory space that is allocated to this file so we currently have two lines that is edu Recon this is my first repository and you can also see the number of contributors to this project that is just one that's just me for now and you can view the history of the commits or the changes that have been performed in your file so we'll come back to that part later on this session but you can move back to your main page of this repository by clicking on the name button here so edureka is the name of my repository so I'm going to click on that so now I'm back to the main page of my Repository before we learn how to create our first Branch let us understand what branches are branches allow you to work on other features that can be included and merged with the master Branch if required so what is the master Branch the master branch is the main branch where your project resides on so all of the changes all of the activities that you do with your main project lies or is on your default branch that is named as the master Branch so what really GitHub allows you to do is it allows you to create additional branches so on these additional branches you can work on the other features or you can experiment with your project and if you're happy with this you can simply merge these features to your main branch that is your master Branch this is what branches are really for so they simply allow you to work on other features that's what branches are so let's move on to the demonstration part and look at how we can create our own branches so now if you look on the left corner you can see a button that says Master So currently we're on the master to branch and there's only one branch and the master branches have already mentioned is the default Branch so when you create a repository you're automatically creating a master Branch so this is where your project will be residing on and now if you want to create another Branch say let's name this Branch one branch so this is what I want to name my additional Branch I'm simply going to name it and I'm going to click on the enter button so it will redirect me to a page so this is the exact replica of your master branch and you can work on this Branch you can work on any other feature or you can add something you can remove something you can really experiment on this branch and if you're happy with this you can merge back this feature or the experimentation that you've been working on to your master Branch right so you can see this readme text file it's exactly the same there's the name of your repository the description of the repository you can click on the readme text file and everything's the absolute same you can quickly switch back to the main page but the only difference is that you're currently on a branch named Branch one branch you're not on your master Branch now if you want to switch back to your master branch and work on it you can click on this button and you'll find the master here you can click on that and it will take you back to your master Branch so you can work on your project so the currently two branches you can see that and everything's normal everything looks simple that's all for branches it's really easy I hope it's clear so you can look for branches here on this bar here that's present here you can also create new ones in the same option so that's all for branches let's move on to the next part of the session make a comment now what are comments comments simply record changes to one or more files in your branches so basically they save the changes that you're making in your project git always assigns each comment a unique identification which is called sha or a hash that identifies the specific changes so for any changes are made to your project files you can simply go back and look at the version history or the history of the each commit you've performed on your project files so that's what really commits are all about it's extremely easy let's go ahead and make our first comment now I'm going to switch to my Branch one branch and I'm going to make my first comment I'm going to click on my readme text file that's the only file currently in our repository so we'll make the change in the readme text file there are three really important icons that are present in the right corner as you can see the first one is a PC icon that says open this file in GitHub desktop so if you click on this file this entire file will open in your GitHub desktop version the next one that is the pencil icon will allow me to edit this particular file that is my readme text file and the third icon is a bin icon which will allow me to delete this file now what we'll be working on is the pencil icon that's the edit this file option I'm going to click on this and I can simply view a space or a file that will allow me to make changes to my readme text file I'm going to add another line here that says this is my first comment this is what I want to add to my readme text file and if I want to preview the changes I'm going to click on this preview changes button you can see that this is my first repository this is my first Commit This is my first comment is the additional piece of information that will be adding to my readme text file and it's highlighted in blue so we know that that's the additional information I'm happy with this change I'm going to switch back to my edit file I'm going to scroll down and if I want to add a description about the change that I'm performing to my file I can do that a good programmer would always add a description to the change that he's making to the project file so other collaborators will view the commit or they view the change they can read the extended description and understand what the change is about so that's a good habit that you must follow but as of now we're not going to do that so I'm going to leave this blank as you can see there are two radio buttons that are currently available the first one says commit directly to the branch one branch this will allow me to make the change or save or make the commit directly to my Branch one branch only so the change that I'm making currently is only implemented to my Branch one branch the second option allows me to create a new Branch for this particular commit and start a pull request we're not going to talk much about this option right now but the first option is extremely important so we let this be stuck onto the option that says commit directly to the branch one branch and I'm going to click on the commit changes options and this will simply implement the entire change to the file you can see that the change is implemented the additional piece of line that says this is my first comment is added to my readme text file now the interesting part is if I switch to my master Branch the change is not implemented in my master Branch so the change is only currently present in my Branch one branch and now if I want to view the history of the changes that I've made I've already mentioned in the previous part of the session that the history button will allow me to do so so I'm going to click on this history button and you can see that I made my first comment 23 minutes ago and I made my new comment 41 seconds ago and there is also a hash number unique hash identification number that allows me to distinguish between both of these changes so all of my comments that I'll be making on this Branch will be available here so that's the main point of a version control system isn't it understanding and keeping a record of all the changes that we're performing in our files and our projects so this is gives full Justice to the word Version Control so that is what GitHub is all about now that we learned how to make our first comment two let's move on to the next part of the session open and merge pull requests so what are pull requests pull requests let you tell other developers about changes you've pushed to branch in a repository on GitHub so once a pull request is open you can acknowledge and review the changes with collaborators and add follow-up commits after which your changes are merged into the base Branch so there are two ways to create a pull request the first one being pulled requests from a forked repository and the second one being pulled request from a branch within a repository currently in this demo we will work on the second one that is pull request from a branch within a repository now I'm simply going to switch to My Demo part okay now currently I'm on my master Branch I'm going to click on this pull request option that's here now it says Branch one has had recent pushes three minutes ago compare and pull requests I'm not going to click on that I'm going to Simply click on the new pull request option here so this will allow me to compare the changes there's a base branch and a compare Branch the based launch is the master branch and the compare Branch I will compare my master Branch to my Branch one branch so this notification says that the merge between the branch one branch and master branch is definitely possible so it's a green signal so if I scroll down I can view the difference between both the branches so the left hand side indicates the information that is present on the master branch and the right hand indicates the information that is present in my Branch one branch plus sign indicates the additional information that is present in my Branch one branch I'm happy with this so I'm simply going to scroll up and create the pull request I'm going to click on that I can also leave a comment and I can preview the change that's not necessary for now so I'm going to go ahead and create the pull request now this will redirect me to a page so this page says that the opal request has been opened and now I can choose to merge this pull request that is I can merge the branch one branch to my master Branch so it says this branch has no conflicts with the base Branch merging can be performed automatically and that's good news right so I'm going to click on merge pull request and I'm going to confirm my merge update my readme text file I'm happy with that so I'm just going to confirm it now it says pull request successfully merged and closed you're all set the branch one branch can be safely deleted I'm not going to delete the branch I'm going to compare both of the branches and see if my master branch is exactly the same as my Branch one branch so I'm going to click on this edureka I'm going to go to my main page of my repository so my master branch has the additional piece of information that says this is my first comment now if I switch to my Branch one branch it has the exact piece of information so the information that was present in my Branch one branch has been successfully implemented to my master Branch so that's all for the pull request part two we've reached the end of the demonstration part now let's quickly look at the case study of how Microsoft implemented GitHub I'm pretty sure most of you have heard of Microsoft Microsoft cooperation is an American multinational technology company it develops manufactures licenses supports and sells different computer software consumer electronics personal computers and other related services so initially Microsoft was against the use of the open source because they held very tightly to the Internet Protocol they were completely hesitant to adapt to this new concept of sharing code to the entire world but in 2010 they rethought this entire scenario and now Microsoft is one of the biggest contributors to open source today about 2000 to 25 000 Microsoft Engineers maintain typescript.net Windows terminal dark Helm and more than a thousand other open source projects so first what they did was they released new processes in measured containment but later on they released only license software so here developers can learn from the company's source code but they couldn't really build on it eventually the stigma died and now even close code like dotnet is open source under an MIT license teams realize that they need to accept contributions to get feedback and learn from other Developers to organize and understand this approach Microsoft created their open source programs office which enables distribution and centralization of knowledge so the ospo provides the resources and maintainers to manage thousands of repositories and contributors effectively on GitHub even though Microsoft invests in its tools they expect other individuals and organizations to lead the way Microsoft believes that github's value isn't in any one feature but its entire Community GitHub is the place to collaborate it's where everyone is and where most of the entire world's open source is already happening it's not just a feature but the whole thing foreign what is a workflow workflow is about controlling the sequence of events that transform a piece of work to ensure every person on the team can use the best tool at the right time to put it simply a workflow is how you get work done it is a series of tasks you need to complete in order to reach some repeatable business goals at its core the workflow is change management as I have already mentioned before workflow comes in all shapes and sizes there is no Universal solution for every team's needs an optimal workflow enables the systematic organization of resources into processes that transform materials provide services or processes information the principal ways to manage software in git are the git flow and the GitHub flow these two methods can really help you to manage your project and optimize your entire workflow in the team now that we know what is the workflow let us discuss about git Flow versus GitHub flow so first we'll discuss about git flow git flow works with different branches to manage each phase of the software development it is suggested to be used when your software has the concept of release because it is not the best decision when you work in a continuous delivery or continuous deployment environment with this particular concept is missing another good point of this flow is that it fits perfectly when you work in a team and one or more developers have to collaborate on the same feature so the main branches in git flow are Master develop features hotfix and the last one is release now let's discuss about GitHub flow GitHub flow is a lightweight branching workflow that supports teams and projects where deployments are made regularly it is centered around a particular feature and small confined changes so now I'll discuss some of the key features of GitHub here the master branch is always production ready Master is also deployed to production development often only happens on the feature branches the deployment speed is extremely fast here and the last important feature is that it requires a verification for each release now let's move on and discuss some of the major issues of get flow so here many of the developers do not like that new feature branches are started off the develop Branch rather than the master Branch or the way it handles hot fixes but these are fairly minor issues but before we move on with the major ones let me explain you what a hot fixes hot fixed branches are a lot like release branches and feature branches except they are solely based on Master instead of the develop this is the only branch that should Fork directly off of the master now moving on to the major issues with Git flow it is much more complicated than most developers and development teams actually require it to be it's complicated enough that a big helper script was developed to help enforce the flow though this is okay the issue is that it cannot be enforced in a git graphical user interface but only on the command line so the only people who have to learn the complex workflow really well because is they have to do all the steps manually are the same people who aren't comfortable with the system enough to use it from the command line this can eventually be a huge problem these issues can be obviously solved easily just by having a much more simplified process so here at GitHub they do not use git flow they use a much simpler git workflow its Simplicity gives it a number of advantages one is that it is easy for people to understand which means they can pick it up extremely quickly and if they ever mess up they can always undo another is that we do not need a wrapper script to help enforce it or follow it so using graphical user interfaces and such are not a problem so the next question that arises is why don't they use git flow at GitHub well the main issue is deployment the git flow process is designed largely around the release Branch GitHub does not really have the release is because your deployment to production occurs every day that is often several times a day the process of testing and shipping is as simple as possible so that every employee feels comfortable doing it now let's move on and understand the main topic of today's session GitHub flow the first step in GitHub flow is to create a branch so when you're working on a project you're going to have a bunch of different features or ideas in progress at any given time some of which are ready to go and others which are not branching exists to help you manage this particular workflow so now when you create a branch in your project you're creating an environment where you can try out new ideas changes you make on a branch do not affect the master Branch so you're free to experiment and commit changes safe in the knowledge that your branch won't be merged until it is ready to be reviewed by someone you already collaborating with you can always switch branches using the git checkout command now branching is a core Concept in git and the entire GitHub flow is solely based upon it there is only one rule anything in the master branch is always Deployable you should remember this so because of this it is extremely important that your new branch is created of the master when working on a particular feature or of particular bug fix your branch name should always be descriptive so others that are working with you can see what you're working on now let's move on to the second step in GitHub flow add commits so once your brand has been created it is time to start making changes whenever you add edit or delete a file you're making a commit and adding them to your branch this process of adding commits keeps track of your progress as you work on a particular feature branch make sure you are on the correct Branch by listing it and if necessary switching to it by using the command git branch and then using the next command get check out your feature Branch name make sure you are on the current Branch by listing it using the get Branch command and if necessary switching to it by using the checkout command comments also create a transparent history of your work that others can follow to understand what you've done and why each comment has an associate comment message which is a description explaining why a particular change was made furthermore each comment is considered a separate unit of change this lets you roll back changes if a bug is found or if you decide to head in a different direction you can do this by adding committing and then finally pushing it comment messages are extremely important especially since git tracks your changes and then displays them as commits once they finally push to the server by writing clear commit messages you can make it easier for other people to follow along and provide feedback the next step is open a pull request pull requests in initiate discussion about your commits because they are tightly integrated with the underlying git repository anyone can see exactly what changes would be merged if they accept your request you can open a pull request at any point during the development process when you have little or no code but want to share some screenshots or general ideas or when you're stuck and need some help or advice or even when you're ready for someone to review your work by using github's at mention system in your pull request message you can simply ask for feedback from specific people or teams so in pull request you can also describe how to test your changes pull requests frame a problem by describing it maybe you're trying to fix a bug add a feature or trying out a new code pattern having a proper problem description ensures that your reviewer knows exactly what you're getting into to let your reviewer know how to run your code describe how to test it properly lay out a scenario that gives a basic run through from setup to the expected outcome are there any multiple angles you can test your feature with awesome specify a test case for each scenario not only does this help your reviewer navigate through your code it also helps you by describing the feature step by step for someone else it ensures you have not missed anything critical now let's move on to the next step that is discuss and review your code once a pull request has been finally open the personal team reviewing your changes may have questions or comments you can obviously read these you can also continue to push to your branch in the light of discussion and feedback about your comments if someone comments that you forgot to do something or if there is a bug in the code you can immediately fix it in your branch and push up the change GitHub will show your new commits and any additional feedback you may receive in the unified pull request view pull request comments are written in markdown so you can embed images and Emoji use pre-formatted text blocks and other lightweight formatting you can even suggest committable changes right in the comment a review basically focuses on the code health and on production Readiness so let me explain you what code health is perhaps the coding style does not match project guidelines the change is missing unit test or maybe everything looks great and props are in order pull requests are designed to end create and capture this type of conversation you can suggest changes directly in a comment by hitting the suggest changes option now let me explain you what production Readiness is the pull request template lays out one or more scenarios on how to test your code the reviewer will go through a scenario and document the results and whether or not the test is passing the reviewer should be generous with comments descriptions and screenshots also ask for any sort of explanation or improvements as the test is progressing the reviewer will also describe if the test scenario passes with this we'll move on to the next step that is test your changes so before any code is finally deployed into production it needs to be test in a production-like environment that is you could say the staging area to make your life easier read upon how to make an update script to update your tool for each environment right here with this we come to the last step of GitHub flow that is merge your feature now that your changes have been verified in a production-like environment it is time to merge your code make sure the code has been signed off before proceeding squashing commits offer pull requests improves the readability of the commit history so during development commit early and often once your work is ready merge with the focus commit message by default the merge button for repositories will be set to squash and merge once merged pull request preserve a record of the historical changes that is made to your code because they're searchable they let anyone go back in time to understand why and how a decision was made speed [Music] what is Bash in the early days of computing the computer that process data or performed operations was separate from the tool that gave it the instructions to do the processing on one hand there was the terminal which was used to send commands to the computer and on the other hand we had the computer the hardware that processed the commands today there are computers that can provide both commands and perform the computation and these computers have graphical user interface that make it easy to perform tasks however accessing the command line or terminal can often be more efficient than using graphical user interfaces for certain tasks and you can send commands via the terminal to programmatically accomplish these tasks now for example working with files in the terminal is much more faster and efficient than working with files in a graphic environment like Windows Explorer or the finder on a Mac you can also use the terminal to launch and execute would open reproducible science tools such as Jupiter notebook Python and git which we will talk about later on in the session before we really understand what is Bash we need to understand what is shell so shell is the program and the information produced is the output now these commands can be entered and executed via the terminal which allows you to control your computer by typing in commands with the keyboard instead of using buttons or drop down menus in a graphical user interface with a mouse or keyboard bash also known as the Born Again shell is an implementation of shell which allows you to efficiently perform many tasks let me explain bash with an example you can use bash to perform operations on multiple files quickly via the command line you can also write and execute scripts in bash just like you do in r or python that can be executed across different operating systems using bash in the terminal is a powerful way of interacting with your computer GUI is in command line bash are complementary by knowing both you will greatly expand the range of tasks you can accomplish with your computer now with bash commands you will be able to perform many tasks more efficiently and automate and replicate workflows across different operating systems like Linux Windows Etc now common tasks that you can run at the command line include checking your current working directory changing directories making a new directory extracting files and finding files on your our computer now working in the terminal with bash provides you with the ability to easily navigate your computer to access and manage files in folders that is you can easily navigate your computer's directories you can also quickly and efficiently work with many files and directories at once also you can run programs that provide more functionality at the command line like for example git you can also launch programs from specific directories on your computer for example Jupiter notebook and finally with the help of bash you can use repeatable commands for these tasks across many different operating systems like Windows Mac and Linux now do we know what is Bash and we've also discussed some of its features let's move on and understand what is git bash git bash is simply an application that provides git command line experience on the operating system the operating system can be anything as usual like Linux Windows Mac Etc now it is a command line shelf for enabling git with the command line in the system a shell is a terminal application used to interface with an operating system through written commands git bash is a package that installs bash some common bash utilities and get on a Windows operating system now in git bash the user really interacts with the repository and the git elements through the commands the next question that really pops up in your mind is what is git right so git is a version control system for tracking changes in source code during software development it is basically designed for coordinating work among programmers but can also be used to try track changes in any set of files so basically its goal is to increase efficiency speed and easily manage large projects through version controlling every git working directory is a full-fledged repository with complete history and full version tracking capabilities independent of network access or a central server git helps the team cope up with the confusion that really tends to happen when multiple people are editing the same files now that we know what is git git bash let's move on to the demo part and learn how to install git bash for Windows now let's download get for Windows I'm just going to Google get bash for Windows and I'm going to click on the first link this will redirect me to the gets official website where I can download git and I'm going to click on Windows option here so once you click on the download link for Windows it will download the executable file now that it has installed we can extract and launch the git installer I'm just going to click on this folder now you can just review the gnu general public license and once you're ready you can just click next the installer will also ask you for an installation location you can just leave the default unless you have any reason to change it and then you can click next once you click next you'll be prompted with the component selection screen and you can just leave the defaults unless you have a specific need to change them and click next now the installer will offer to create a start menu folder just you can click next now you can just select a text editor you'd like to use with Git use the drop down menu to select whatever you'd need for your convenience I'm going to be selecting notepad plus plus and then I'm going to click next if you do not have notepad plus plus installed onto your system you can just click this link and then just install it will take you a minute then just click on next now this installation step allows you to change the path environment path is the default set of directories included when you run a command from the command line leave this on the middle that is recommended selection and then you can just click next the next option relates to server certificates most users should use the default if you're working in an active directory environment you may need to switch to Windows store certificates so you can just click next now the next election converts line endings it is recommended that you leave the default section this relates to the way data is formatted and changing this option May really cause problems so you can just click next now you can just choose the terminal emulator you want to use the default Min TTY is recommended for its features you can just click next in this option you can choose the default behavior of git pull I'm just going to leave it as default and click next now here you can just choose a credential helper I'm just going to let it be on default click next I'm going to enable file system caching I'm going to click next now currently the option to include interactive options is offered here unless you're feeling adventurous leave them unchecked and then just click install now once the installation is complete tick the boxes to view the release notes or launch get bash then just click finish and as you can see git has launched the release notes I'm just going to open this you can just read the release notes I'm just going to close that window now git has two modes of views okay the first one is a bash scripting shell or you could say the command line and a graphical user interface now in this tutorial we're going to be using the bash scripting shell that is our command line now to launch git bash shell you can just open your Windows start menu and type get Bash okay and this will take you to your get bash I'm just going to zoom in yes perfect now if you'd want to create new directories that is just folders in Git You can just use the mkdir command now I'm just going to create a new directory named git underscore demo now I can change the location to the newly created directory by using the command CD and type the name of the directory that I'd like to move in that's git underscore demo and you can see that I have moved into my git demo directory also you can use the ls commands to list all the files and folders in the current directory I'm just going to type LS because it has none it's not going to show you any now if I want to move back to my previous directory I can just click on the CD command and put in two dots and this will take me back to my previous directory and if I click LS you can see all of the documents that are currently present in my directory you can see that I have pictures I have videos I have Anaconda I have a folder named git demo this is great okay now what I want to do is I want to create a username and I want to create an email for working on get bash and for this I can use the command git config hyphen hyphen global user dot name and I'm just going to type in my first and last name okay and this has created the username for me now I want to set my email address so I'm just going to type the same command but I'm going to refer this to email and I'm just going to type in my email okay once that is done I have set up both my username and email now let's move on to the next part of this session and learn how to initialize a local repository okay so now what I'm gonna do is I will clear my screen now what we've really done is we've set our git username for every repository on our computer and once that is done I just want to check if the username has been set I'm just going to use this command now that I have confirmed I have set my get username correctly let's move on to the next part so firstly Let Me Clear My screen for this now there are some few basic commands that you have to be familiar with when you start off with Git and get bash so I'm going to be talking about some of those commands the first one is who am I now the commands output is the ID of the current user when you type who am I the shell finds a program called who am I runs that particular program and displays that program's output that is your username and then eventually displays a new prompt to tell us that it is ready for more commands now let's try another command that is PWD which stands for print working directory now when you first log in right your current working directory is your home directory okay and your home directory has the same name as your username and this is where your personal files and sub directories are saved so PWD is that and as I've already mentioned before to find out what is currently in your home directory you can use the ls command and LS just prints the names of the files and directories in the current directory in alphabetical order arrange neatly into columns now the number of commands have extra options of features which we can call through the use of a flag now a flag is usually a dash followed by a single letter such as Dash V Dash L Etc I am just going to type the command LS Dash L okay so the dash L flag on the ls command is short for long format and it really displays a more detailed listing of all the files within the current working directory including file size and the date of its last modification now you have to remember that there is a space between LS and dash L without it the shell things we're just trying to run a command called ls-l which doesn't really exist let's take another example of the flag I'm just going to type LS Dash F okay now this command tells LS to add a trailing to the name of the directories here we can see the list of all the subdirectories that are present now Fields like links music all of them have trailing slashes and there are ton of online manuals that really tell you which options a particular command can take and how each option modifies the behavior of the command now I'm just simply going to clear my screen and one more thing I forgot to mention is that if you want to check that git is up and running and is installed properly you can obviously use the get help command and it will just give you an overview of what is in git and if it's up and running now we will just move into the directory git demo so I'm just going to use the change directory command and this will just move me to my git demo directory now I will tell my git to create a repository okay for all of you all who don't know what a repository is it is a storage area where a version control system really stores all revisions of files and information about who changed them and when did they change them Etc it's basically a storage space for your file okay and each version of the changes that you make in these files are stored in a repository okay that's what a repository is now let's move on and initialize this repository by using the get init command it'll prompt you with a note that's says initialize empty get repository in this particular location okay so that's great now let's look at what is in our directory you don't have anything and as you can see that this is currently the master branch that we're working on so the master branch is the main branch of your repository where all of the changes to your project is directly implemented okay so branches is completely a different topic on its own so we'll not really talk about it in detail so I'd like to talk a little bit about the init command so the initialization command really creates a hidden directory and you can see that it has created a hidden directory that is named as dot kit okay now get really stores information about the project in the special dot get subdirectory now if we delete this file even by mistake what really happens is we lose the entire Project's history okay so the next command that we'll be learning about is the get status command I'm just going to click enter and you can see that it says on Branch Master no comments yet nothing to commit okay now first of all this gives a lot of information right it states that firstly we're located on the master Branch so we haven't made any comments yet comments just allow you to save the progress of your files on git so as we have not made any comments yet it just indicates that so we haven't created any files so it says nothing to commit and I'm just going to clear my screen so now what I'm going to do is I'm going to create a file using the touch command I'm going to name this file demo too so basically this is a text file so I'm just going to add the extension.txt and I'm just going to list now you can see that this directory has a file a new file which has been named demo.txt so now we're going to use the command git add demo.txt and then check the status of git now you can see that there's been a change right so in the third notification you can see that changes are to be committed to the new file demo.txt okay so this is great what we're going to do is now we are going to commit this so before I commit it and save it I'm just going to explain you what use get RM dash dash cached file to unstaged means so this command really removes your current file from the staging area okay currently our file is in the staging area so we're just going to commit it by using the command git commit and if you'd like to add a message you can just use the dash M open the semicolon and type your message so I'm just going to type first commit once that is done you can see that our first comment has been successfully made and one file has been changed the zero insertions and zero deletions you can check the status again you can see that nothing is that commit and the working tree is clean so this is how it really works the git Cycle Works this is the basic structure of it once a directory set up as a git repository using the git init command any change that we make to that directory is noted by get so the first is you either create a new folders and files in your directory or you can even modify it we haven't done that yet and the second stage is you stage these changes ready to commit by using the git add command and then finally you commit the changes using git commit which permanently saves the current version of that Repository so these are the major three steps you create new folders and files you stage them by using the git add command and then you finally commit these changes so now that we know the basic commands of get let's move on to the next part of the session I'm going to clear my screen so Version Control really comes into its own when we begin to collaborate with other people right in practice groups like to use a central Hub or a cloud stored on the web rather than on somebody's laptop so that all the collaborators can easily access the repository git is very popular because of websites like GitHub bitbucket which make collaboration extremely easy now what we're going to do is we are going to go to GitHub so in short GitHub is really a web hosting platform for you to collaborate with other team members and I'm just going to sign in because I already have an accountant GitHub I'm just going to sign in I'm going to enter my credentials that is my username or email address and password if you do not have a GitHub profile I would suggest you to create a new account it's really easy and I'm just going to sign in and this will redirect you to your GitHub account you can see that you have a navigation bar on the top which has some options like pull request issues Marketplace Explorer you can also check out your profile your status your projects and all the repositories that you're currently working on GitHub okay so what we're going to do now is we're going to create a new Repository so what is the difference between the repository that we created on git bash and the repository that we're going to create on GitHub so the one that we created on bash is a local repository that is solely for your local machine that you're working on but the repository that we're going to create on GitHub is on a central repository so when you create this repository the team members your friends your family can really look into this repository and look at all the files and folders that are present on your GitHub repository okay so we're just going to create a remote repository I'm just going to name this repository demo and you can add a description to your repository if you'd like to also I'm just going to add a readme file and then I will create Repository now once this is done I'm just going to click on this green button that says code and this will give me an https link I'm just going to copy this link what we're really going to do is we're going to connect both of these repositories we can do this by making the GitHub repository a remote for the local repository okay now the home page of the repository on GitHub includes the string we need to identify it which we've already copied now since we have already created a repository on a local computer we're interested in the instructions in the second box so we're making sure we are in the demo directory locally and we're going to do this by using the command git remote set Dash URL origin and we're going to paste the https URL that we've copied from GitHub so we click this code and then we copy this https link so that's exactly what we're going to do we're just going to add that and click enter so what really this command does is it tells get to add a remote named origin at this particular URL fine I hope this is clear now you must be wondering what is the keyword origin okay so this is simply a nickname that we have assigned to the particular remote repository we could have it called anything but origin is the most common choice for programmers now if we have to check the command work right so we're just going to use the git remote Dash V now that you can see it lists all of the remote repositories that are present on my GitHub profile now the dash V flag is short for were boys which really tells get to show the remote URL as well as the nickname so so far what we have done is we have set up a remote repository and linked it to a local repository so the remote repository currently is empty it doesn't have any files it just has a readme text file I want to add my demo.txt file that is present on my local repository into my remote repository that's what we're going to do and we can do this by you know pushing the changes from our local repository to the repository on GitHub we can use the command git push origin master and this will pop up a window which will allow me to connect to GitHub okay you can either connect to GitHub with the help of a personal access token or you can also sign in with your browser I'm just going to sign in with my browser you can see that you can just authorize git credential manager the authentication has succeeded so now our local and remote repositories are synced so that's great now you can just view that the files have been reflected into our remote repository and if I click on the master branch which is the name of the branch that we were currently working on our local repository we have a demo.txt file you can quickly switch back to your main branch too and you can see the readme file that was created initially on a remote Repository so this is how simple it is to work with Git bash and also with GitHub it's really easy it's really interesting I hope you had a great time understanding the basics of git bash and how it really works and what it is all about [Music] how do we configure remote repository on a local machine what we're trying to do we are trying to do is that we have a existing project on our local machine and we have not added the git remote so what we're going to do is we're adding the get remote so if I go back to get LS if I do get remote then there is none so what I'm gonna do is I'm gonna copy the remote URL from here and I'll go to this project hello world I'll copy the remote URL and I have to execute this command get remote add and then the remote name and then the repository name so I'm gonna do is origin and this is my repository URL so if I now do get removed I should see now origin I can also see it barbos let's see so remote name is the name for the remote and the remote URL is the remote repositories URL that I just copied from the GitHub I can see the detail link between the remote repository name and the URL which is here so I have my origin and this is my remote URL for push it is also the same this is another demo we are doing wherein we are configuring existing project as a remote repository so what we are going to do is we are going to create a new repository on GitHub we will open the get bash and initialize the project and once that is initialized I'll add all all files in the local repository by adding get add dot then this stage file for the first comment so once that is there I'll make my first commit as get commit minus M and then we will add the remote so let's I'll start with this so let's create a new repository on the GitHub I'll go to new Repository this is public and I'll initialize with 3d.md and I'll take the license as chain General product so I'm creating my repository my repository is created now I can go back here and let's me so I'll create new project my project too I will add a new file desktop txt and I'll initialize my die screen so get I've initialized the directory I can look at the guest status now so I have untracked file I'm gonna add it this is my first comment so I'm committing this file from staging area to the repository now this is committed now what I have to do is I'll add my ADD remote repository so if I go to get remote to look at the repositories then they should be numb so what I'm gonna do is I'm gonna copy this remote URL repository URL I'm gonna do get remote at the name and then the get now if I do remote minus V I have my get ready now get push origin master so what we did is we didn't integrated the remote changes so before this the push I'll have to do a pull here because we have readme.md file so I have my now I so what I did is there was some issue with my brand so what I did is I just re-based my prawns and if I look here now I'll do is I'll push it to the origin master so now I have uploaded the project so what we did is we created a new project and when we uploaded this file we added the remote URL remote repository URL and we have uploaded the file so we can see the remote repository that we already knew that we can type get remote and do minus V and it will show us the URLs that git has stored it will list all the remote servers which are there so this is what we are talking about get remote I can get origin and if I add minus v i can get all the URLs I can also rename a remote repository for example instead of origin I want to for example if I have different remote repositories then I can for example name it something else let's so what I'm going to do is I'm gonna I'm gonna rename the origin to repo one if I do now get remote so I have rapperman now so this is just for the renaming a remote repository name now to remove a remote repository we can use either the below options so they both the same commands first one is get removed remove and the second one is gate remove RM these two commands the reason for removing can be that maybe the server has moved and we are not using that particular mirror or our contributor is not contributing any more in the project so there can be n number of reasons for removing the branch in case the server has been moved then we first remove the remote repository and then we will add the remote repository again that we saw in the previous examples the point here to note is that all remote tracking branches and configuration settings will also be deleted for that particular remote repository so how can we check the remote repository so I'm gonna do get remote minus V so I have the ticket repository named origin with the git URL is listed so to remove it what I can do is I can either use get remote RM and then the branch name now if I check this again then this will return me a blank result so now let's take an example what I'm going to do is I'll quickly remove my module 3. so I'll quickly clone this this is the same we are using since I have removed the remote instead of adding the remote cloning is much faster for me now so I'm gonna get into this and this is I have the remote available so what I'm gonna do is let's check the branches and then execute the command so we have only one branch which is Master which is the default Branch so now I'm going to create another Branch let's name it as Old Branch well now since we will cover this in more detail in the coming slides but for now you have to understand that when I execute the code get Branch Old Branch or the branch name then this branch is created on the local module then this branch is created on my local repository and I have to push it to the remote repository so the command to push it is get push then the remote repository name and the branch name so this branch is moved I'm gonna open another window for Chrome and now what I'm trying to do is we're going to go to the GitHub and see if the branch has been created successfully or not so I'll go to my repositories module TV and yes there is an Old Branch right now since we have the Old Branch available on get remote so now let's remove this Branch or delete this branch and the command to delete is same the only thing that I'll add is Allah delete after the repository name so get push origin dash dash delete Port branch so let's go back again to this and see EFT so now I have only one branch which is master let's create another new branch and let's sorry not the push but I'll have to first create it so I'll do great Branch New Branch and then get Branch this will show the new Branch okay the point here to note is that as I said the when I deleted the branch from the remote and it was only deleted from the remote if you can see here there's only one branch and this Old Branch is not deleted from the repository to delete this Branch completely or any branch completely the steps will be first to delete it from the remote second to delete it from the local so to delete it from the local I'm gonna do Branch minus D and the Old Branch name now if I do grid Branch I only have one branch which is get and now I'm gonna push this new Branch again to origin and then the knee Branch name yes so now I have another branch which is New Branch now I can also go ahead and rename a branch so to rename branch on the remote repository you need to First rename a branch on the local repository once that rename is done you will then push it to remote by with the same name for commands so let's check this for example here what we're doing is we are checking out a new Branch we are creating a new Branch Old Branch and at the same time we are also switching that Branch again so this whole one single step can be broken down into two number one we create a branch with grid Branch Old Branch and number two we check out we switch to the Old Branch using get checkout or Branch but this single command will do the boots thing it will create a new branch and then switch it on it so if I do get branch then I have only New Branch so let's do git checkout so you see it has created new branch and switched to it but this is the local brand this Branch does not exist on the remote so far there's only New Branch there are two branches master and New Branch next what I'll do is I'll push this Branch to the remote so the command is same git push the remote repository name and the branch name okay now I have three branches Master new branch and the Old Branch and if I do this command before I rename so let's rename it to here what is happening is that when we create this Branch we had only one two branches master and Old Branch and then they are renaming this Old Branch to New Branch so let's rename this Old Branch to actually New Branch Norm New Branch one so the command is get Branch minus M the Old Branch name and then New Branch one if I do now get Branch then I have again three branches Master new branch and the new Branch one but if I go to the remote again then I have not pushed this change to the remote yet so I have only three branches Master new branch and Old Branch this has not been renamed on the remote so to rename it on the remote what I'll do is I'll push this Branch get push and what I'm going to do is get push call on if we now go to this branch and let's check the branch name so the Old Branch name has now been changed to new Branch 1 on the remote as well while if we go to this example then what is happening is that we have created a new Branch new Temp and then switched to that branch so the minus M option here is for moving or renaming a branch so generally the command follows this get Branch minus M the Old Branch name and the new Branch name if if we go and try this example then get Branch minus M let's call it temp new Temp and then we are going to move temp to Newton but the issue here is that they already have temp so let's create first of all temp here okay if I do now get Branch then I have temp so the First Command what happened is if you remember our new Branch 1 has been renium to Temp so if I'm not providing the second argument it will consider the default branch which is selected or the current branch which I am on as the branch which has to be renamed now if I'll move temp to new temp if I do now the gauge Branch then temp has been renamed to newtamp in the last step I'm pushing this but let's see if it will push or not but I think it will I'm not sure if it'll work because we don't have the temp on the remote let's see it has failed to push why because I don't have the new Branch I have not pushed the temp so let's rename this to Temp again and then let's put new Branch one to temp so now I have the command temp now also sorry the branch name temp and now if I move this temp to new temp and then push it to the remote repository then this will work as well in the same way we can delete the remote Branch we already saw this example but let's now delete this branch that we created so the command is this push then we pass the dash delete option and then the remote repository name and then the branch name so minus t origin new underscore temp plugin as for password if you are working on remote I strongly suggest that you should consider setting up the passwordless SSH so this branch is now deleted let's verify it yes now we have two branches master and New Branch we deleted the new temp now this is the another option we have in when we are pushing our changes to the remote which is the minus F or the force push flag so get push minus f is a short for Kit push hyphen hyphen Force option if I go and we can try up so this is the option we are talking about Force so this option will force a push when otherwise get would reject your get push because you might have changed your repository history in pushing your repository so Force push also lets you overwrite someone else's comment which have been pushed after your last work for example let's consider that your repository is at commit a and you change something locally and committed so this now becomes the commit P you push commit B to your remote repo so both are now B now now you decide to change something again and replace your commit B by commit B hyphen now you want to push your commit B hyphen changes to the remote repository a plane get push will not work so you can now remove commit B from your remote repository and push B hyphen instead with get push dash dash Force so what will happen is it will override the changes and will replace your branch directly be aware that Force pushing is the highly dangerous and unclean solution when you are working in a shared repository so instead of you someone else might have pushed for example B hyphen and if you're trying to commit now be hyphen hyphen then you'll get a merge conflict and in that case to resolve the Munch conflict you can overwrite your changes however that is not recommended and that is unclean so all comments in the shared repository should be considered immutable this is the best practice and to keep your repository consistent and keep your co-workers happy you should use git revert instead or you should go for manually merging the conflicts which we'll see in the next module so let's try this git push example let's see how the get push will work so what I'm gonna do is I'm gonna go to test.txt and let's update some content in it it says add it from remote let's change it to remote one another line from GitHub let's commit those changes so what has happening now I have a different version on the remote which we can consider that someone else pushed it and we have a different version on the local so now let's update our local repository please note that we are not merging the changes we are only updating our local Repository I'm assuming we were on Master yes and get branch let's check out the master as well so now I have also fetched the master repository here now you can see that my changes are there and but they are not been pushed into my file yet or merged into my file yet I still have added from remote but not that so if I go ahead and change my repository for example let's change the test.txt before that first check the status so there's nothing to commit via clean so let's edit test.txt and let's add this line This is added from local repository I'm again again saying I'm using emacs editor here if you are comfortable with Vim or Nano you can just go ahead and use that now what I did is I updated the file but that is not in the staging area so let's move it to the staging area now it is in stages and now I am gonna commit it added line from local rapport our workspace I can see so now we have our remote is on different commit and my local is on different command so what I'm going to do is now if I go ahead and if I try get push origin Master then this will be rejected so let's okay it's authentication fail let me try it again so this is rejected why because the tip of my current branch is behind its remote counterpart so we have to integrate the remote changes before pushing again so now I have two options either I merge them manually which is called as the merge conflict which we'll see in the coming slides but for now we can have unclean solution which is overwriting all the changes so what I'm going to do is I'm gonna just add a force option here before the get so not before not after the get but after the get push so you see now my changes have been pushed here and this changes another line for GitHub has been removed completely so it has overwritten my file if I go to the history then I can see that I have this added line from the workspace but I don't have that change wherein I added line from the local from the GitHub once you have merged the force update or once we have did the force push to the depository let's look at the file locations in both pre and post command so any file will can exist in three locations which we already know what this location are and the same file can have different content and different locations so the first one is remote inside the repository so this is the remote which is for example is in GitHub second is stage in the index so this one is ready for commit and is the staged area third is the workspace which is not in the staged area but it is in a workspace so far so content of these file as it was last committed to the repository this is in the repository this is on our local but second one is in this stage and ready to commit well the first one is not a stage yet and most files are in progress State get wound would do an auto update for a stage file with additional edit to do that we need to explicitly add our files from the workspace to the staged area using the getaded command which we already saw in the previous examples the next thing we have is compare remote wrappers so we already saw how the conflicts can happen so this comparing the remote repository will come in handy with the conflicts when we'll come to that but we can also compare our file with the remote one or between the two locations or between the two files or commit hash different options if we do not specify any option then it will compare to the staged or the index version to compare the stage version with the committed version so committed version is what is in the remote area we have to use dash dash test additional different options are comparing file within two files on the desk comparing with two comments or comparing file without any comment so the command is get diff which is this let's look at the help for get depth so this will show changes between comets commit and the button tree Etc we have different options options can be dash dash cached or and we can compare different files so let's do a specific first thing so let's compare we are not providing any option the workspace to the staged version so let's do get diff test DOT txt first edit our test.txt if I look at the status now we have up to date right so let's edit test.txt and let's add this this line is forget diff now let's compare this file so if you see we are comparing it with the index version we have a b and we have added this line this line is forget diff this will appear in the green color but if I go ahead and remove the line and if I do git diff then what is happening is I have a red color which is seeing this line has been deleted and I have a plus color there is a blank line inserted and then there is another line inserted now what I'm gonna do is I'm gonna add this to staged area if I look at the status now then this is added the stage area now if I do get div then there are no changes because I'm comparing test.txt to one that is staged to compare it with the remote I have to use cached this is added from the remote the same comparison is the same that this line is deleted and these two lines the one blank line and one additional line has been added but this is now compared to the remote I can also go ahead and compare the two files so let's create another file e-test dot text oh let's rename it to New test Dot txt and let's add this is added from remote sorry not remote let's make it from local now I can use git diff to compare these two files not get there if I can directly use the div command test.txt and new test.txt so I can clearly see that I have these changes this is my line one this is my file one which is test.txt and this is my file tool which is newtest.txt and the changes have been are differentiated from this line dash dash if I copy test.txt now to newtest.txt then these are integral but if I go ahead and just added a single word then you see the only this line is coming as the difference so there is f missing but this complete line will be treated as a different line we can also go ahead and compare the two commets so we check this options We compare two files now we can compare two commits as well and how to do that commits can be identified with the commit ID so if I do git log I'll have the commit ID now I can compare them so let's do get diff let's copy these so I'm gonna copy two different commit IDs and if I do this then it is saying me that there were two files test.txtntest.txt and this line has been removed if I look at the their comments then this is 965 which is update text file or let's compare these two let's compare the latest one and this one so this line is not there in the first file which is test.txt which is the latest comment this is added from local repository hats is there is not there in the other file we can also go ahead and compare file with any comment so how can I do it you can again let's look at the log and then compare with let's copy this what I did is I compared this commit ID with the workspace file now there are other options as well that we can compare with any two files on the disk which we already saw we can compare two commands we can compare any file with any comment now to compare local branch with the remote we already saw how this can happen that someone else might have contributed in the in his copy and then push that changes to the remote while we have not pulled the changes here so first what we have to do we have to update our remote tracking branches how do we do that we do get fetch and the remote Branch name now remote Branch name is origin for example this is default one yes what I can do is I can do git diff Master branch and the remote Branch path what is the remote Branch path how does it different from the master so if I do get branch Master is my master Branch path while remote Branch path will become origin slash Master the remote Branch name slash the remote repository name slash the branch name let's go back to this again let's open some file let's edit it and then do a get fat so what I'm gonna do is I'm going to add compare remote let's remove this let's commit this file for compare now what I'm going to do is I'm going to fetch this changes to the repository get fetch origin repository name so what is there we update the remote tracking branches so this is my remote tracking branch and this is my master Branch next what I'll do is I'll do a quick def get div master and then origin Master what we saw is we have compared the master Branch with the remote Master Branch right origin slash master so what we did is we first fetch the remote tracking branch and then we compared them now this command will list all the branches so you can see that Master knee Branch new tab and then wheat is also showing the remote branches so we can choose the branch name from there for example this option that we already saw Masters origin slash Master we Masters the local Master branch and origin slash Master is a remote name lay origin and master Branch so origin is the remote repository name and master is the branch name so Fork is the another command that we have in the gift about so what happens is that we will it allows us to copy other repositories for our own use so we can experiment with the changes or we can go ahead and start the development from that Branch so this is like a very popular and the useful feature of GitHub mainly so it acts as the bridge between original repository and the personal copy by personal copy we mean that we can copy the data the complete meta return the repository and then we can start working on it the only thing we won't get are the settings so this is core of the social coding which is called as open source at GitHub so folks are used to suggest changes changes or to use someone else's project as a beginning point for your own for example if someone has done this is very popular when you come to blogging for example if you're using some theme or some blogs or maybe you're building some analytics project of your own and someone has already contributed to the GitHub then you can focus that repository and then you can start contributing in it of course you will have to check the license if you're building that product for or developing that code for the remote for the production use then you will have to check the license and then you can start contributing so the best example of using folks is for bug fixes where you Fork the repository for fixed issues and raise pull requests to merge in with the original Branch so it is a two-step process one on GitHub we go to the repository and click on the four button after folk to work on local repository you can either clone it or download it for example so what I'm gonna do is I'm gonna go to some username for example and I'm gonna go to let's say the bit start not the best starter I'm gonna go to this credit card analyzer and I'm gonna this repository for my use so if I fork it so now this repository is available for my use right I can now use this as a starting point from a project and to use this I have to clone it again so if you see the repository name has my username the repository URL has my username so I go ahead and I clone it so I have this repository at my this local workspace for my use so I can add anything and then commit push it for example let's add this file this line should be treated as dummy I add this and I commit this added to me line and now I push it so let me check the first punch get and the remote get push origin and then Master then it will ask for my credentials so if I go here and check the history then I have this Dummy Line available but if I go there for the place where it is forked from then you can clearly see that the change does not exist there so I have this copy of the project as my Repository git is a largely distributed which means there is no inherent concept of upstream and downstream it depends on the way data flows for example the other wrapper will be Upstream even well data is pushed onto it and if I am pulling from the other repo then upper other repository is Upstream in my repository is Downstream for example the incredit card analyzer project this the repository of this user is Upstream while my copy is Downstream this is relative between the two repositories so two sync changes which are in the original repository which we have forked we configure a remote that points to the Upstream repository and to do it we have to do what we have to just use this command get remote add up a screen and the repository name so if I do get remote minus V let me first copy the repository URL and if I go here and if I do then I have to add this I have added the Upstream if I didn't do the remote minus V then you can see I can see the Upstream URLs for both Fetch and the remote which contains the original owner of the Repository I can also do this sync so instead I can use the Upstream repository name and then I can check out the folks local branch so this is the Four Queens the downstream repository so this is similar to other this will work like at any other repository on my local if I do get Branch then I can see there's only one branch but the remote are different we can also consider merging it so instead of using origin I can use Upstream we already up to date I can also do the get diff or let's say not the diff but the difference is that this line should be treated as dummy does not exist in the Upstream it is only in my remote repository so this is the change that I can see why it is only showing the my branches Upstream so I cannot go ahead and make changes in the Upstream because I don't have the ownership I can suggest changes and then it will be up to the approval of it however if something has been changed in the Upstream then what I can do is I can merge it with my local repository which will be similar to pull so it will pull the data onto my local repository and I can work on it so now coming to pull pull is the very useful command we have been using it so this is like opposite of potion push we are pushing from local repository to the remote while in pull we are downloading the data from remote to the local so that downloaded data has been pushed by some other user for some other comment or from from the feature might be they have added some feature or they have added some bug fix or they have changed something so we are downloading we are updating our repository on our local so this is the source repository and we have feature source as the branch name we do a pull request and then this is our destination repository and this is the master destination repository this is the branch name the master Branch name so how it will work is that if someone has added something in the destination repository then I can pull it onto my local Repository so this is commonly used by this is a very general command in the get which is commonly used by teams and organization which have more than one contributor so developers work on their feature branch and raise a pull request to merge to Shared Repository what it means is that that we can have multiple branches and then we can have a pull request created open source projects usually pull request to manage changes from different contributors because open source projects have many contributors who are contributing to them so they use pull requests to manage the changes now how do we create a pull request now after we have made changes to the fork after we have forked the project we create a pull request to ask Upstream request repository to merge our changes we are not committing them directly the word here to note is the ask so below the steps we confirm the repository we want to change we select the branch of the Upstream repository to merge and we use the base Branch from the drop down one menu once we selected the document menu we select your fork using the headphone drop down menu which is this and then we select the branch we want to make changes from compare Branch doctor menu so let's take this example so let's push we already have post something right so what I'm going to do is I'm creating to create a pull request before I go here let's read what is saying so pull requests help you collaborate on code with other people as pull requests are created they will appear here in searchable and filterable list to get started we should create a pull request so let's create one this is our base Branch base branch is the original Branch this is our head folk so the base Branch name is master again we have only one branch and the master now we can see the comparison we have added one line and there is no change as such this commits has been made by dudika global which has added a dummy line these are the comments and this is done on December 3rd 2018 so we have one change file with two Edition one is the blank line and second is the line we added now you can also see the split view right this is the split view this is the base copy and this is our working copy the address GitHub so let's create a pull request so now we have added a dummy line and it says it is not wash but it says it wants to merge one commit into aishwary Master form advika GitHub Master Branch this branch has no conflict with the peace punch now if I go here then we won't be seeing this because till the time someone approves it now this is the pull request we are seeing before we do that let's see if this has been added in the readme.md which we are seeing here we won't be seeing here because this has not been approved but we can go to pull request and we can see it here so let's try to open this as a public user so we're getting the whole history we are saying that we this is the commit and this is the file changed so we can clearly see once someone approves it then this change will actually appear in the original repository which is here so This Is How They manage with open source project which have millions of developers they forget they work on their own and then they create a pull request so we are providing title and description and then we can also control the access which is appearing at the bottom which allows for edits for maintenance so if someone else can might change your pull request make a small change here and there we click on pull request and it will be available [Music] now the continuous methodologies of software development are based on automating the execution of scripts to minimize the chance of introducing errors while developing applications they require less human intervention or even no intervention at all from the development of new code until its deployment it involves continuous building and deploying code changes at every small iteration reducing the chance of deploying new code based on budget or failed previous versions there are three main approaches to this methodology each of them to be applied according to Wordpress your strategy continuous integration consider multiple developers working on an app this application has its code stored in each of their respective local repositories But ultimately there has to be one code isn't it therefore all the involved developers push their code changes to a common remote repository to the code this happens every day multiple times a day till the code is complete this practice is known as continuous us integration for every chain submitted to an application it's built and tested automatically and continuously ensuring the introduce changes pass all tests guidelines and Code Compliance standards you established for your app eventually decreasing the chance of introducing errors in your application continuous delivery this is a Step Beyond continuous integration your application is not only Built and tested at every code change pushed to the code base but as an additional step it is also deployed continuously though the deployments are triggered manually this method ensures that the code is checked automatically but requires human intervention to manually and strategically trigger the deployment of the changes continuous deployment this is also a Step Beyond continuous integration similar to continuous delivery the difference is that instead of deploying your application manually you set it to be deployed automatically this does not require human intervention at all to have your application deployed if we take a deeper look into the basic workflow we can see each stage of devops lifecycle so you basically verify package and release your application using the CI CD pipeline this has quite a few advantages in the deployment and production environment including but not limited to increased speed of operation communication between teams regular feedback due to frequent deployment Cycles easier detection of Errors resulting in early recovery now that we have some idea about cicd let's dive a little deeper into the element which makes it all possible pipelines so what are pipelines pipelines are basically the fundamental building blocks of cicd and are hence the backbone of modern devops environment a CI CD pipeline Bridges the gap between development and operations team by automating the building testing and deployment of applications it basically helps to automate a series of steps or stages in your software development process such as initiating code builds running tests deploying and staging production environments and everything in between it provides a more standardized approach to feedback loops reducing errors and paces of iterations of development now there are different stages in pipeline implementation which lays a strong foundation for the continuous everything we all so desperately seek to achieve at number one is commit in this stage new codes are integrated to the base code you have a feedback loop to help check the code quality and a series of unit tests and Sanity tests for the same this is not to be mistaken with the testing stage that comes later in the pipeline implementation next up is build once the code is tested and integrated in the next stage the code is built this is where the source code is converted into an executable form that can be run on a machine the testing stage in the testing stage the alpha and beta deployments take place the former checks the integration between various builds at hand while the latter to check if the app is working before moving it to production the deployment stage once the build has gone through all the test scenarios successfully it is ready to be deployed to the production stage you then finally move to the fourth and final stage and deploy your application and your app goes live for the end user environment that is your consumers now there are a couple of tools popular for being able to automate this entire process two big names you'd often hear are Jenkins and gitlab CI CD to know more about Jenkins you can check out the extensive Jenkins playlist on our Channel but today we are going to tackle the big name that is gitlab cicd gitlab cicd is a powerful tool into gitlab that allows you to apply all the continuous methods that is continuous integration continuous delivery and continuous deployment to your software with no third party application or integration needed to use gitlab cicd all you need is an application code base hosted in a git repository and for your build test and deployment scripts to be specified in a file called gitlab ci.yml located in the root path of your repository in this file you can Define scripts you want to run Define include and cache dependencies choose commands that you want to run in sequence and those you want to run in parallel Define where you want to deploy your application and specify whether you want to run your scripts automatically or trigger any of them manually once you're familiar with gitlab cicd you can add more steps in the configuration file to add scripts to the file you'll need to organize them in a sequence that suits your application and are in accordance with the tests you wish to perform to visualize this process imagine that all the scripts you add to the configuration file are same as the commands that you run on the terminal on your computer so here is an example of the simplest pipeline configuration that can be using a minimal Docker image based on Alpine Linux you have to build build a build something and build B build something else this pipeline will run everything in build stage concurrently and once all of those finish it will run everything in the test stage the same way and then deploy A and B now this pipeline needs to become configured using a yaml file called as the gitlab cicd.yml within each project the gitlab ci.yml file defines the structure and Order of the pipelines and determines what to execute and what decisions to make when specific conditions are encountered say for example when a process succeeds or fails here's the yaml file for the same pipeline diagram we saw before you can see all the different stages in the pipeline that is build test and deploy and each stage has a script to be printed to depict what's going on in that particular stage fairly simple isn't it now know that it's a very rudimentary Pipeline and definitely not the most efficient and if you have lots of steps it can grow quite complex but it's easy to maintain there are other pipelines for that such as direct acyclic graphs and parents child pipelines but since we are just starting out a basic pipeline is what we are going to understand and Implement later on in the the session once you've added the configuration file which is the yaml file to your repository gitlab will detect it and run your scripts with the tool called gitlab Runner which was similar to your terminal the scripts are grouped into jobs and together they compose a pipeline it is designed to run on gnu Linux Mac OS and Windows operating systems gitlab cicd not only executes the jobs that you've set but also shows you what exactly happens during the execution just as you would see in your terminal you create the strategy for your application and gitlab runs the pipeline for you according to what you've defined your pipeline status is also displayed by gitlab at the end if anything goes wrong you can easily roll back all the changes consider the following example for how gitlab CI CD fits in a common deployment workflow assume that you have discussed a code implementation in an issue and worked locally on your proposed changes once you push your commits to a future branch in a remote repository in gitlab the CI CD pipeline set for your project is triggered by doing so gitlab CI CD runs automated Scripts that can be sequential or parallel to build and test your application and preview the changes per merge request once you're happy with your implementation you can get your code reviewed and approved merge the feature Branch into the default Branch gitlab cicd deploys your changes automatically to a production environment and finally you and your team can easily roll back if something goes wrong gitlab cicd is capable of doing a lot more now that you know about gitlab cicd let's install and set up what we need to be able to run our pipeline so first things first let's install gitlab I'm running Ubuntu 19 on my virtual machine so let's open the terminal first we need to install a few packages to install the git lab and those are the open SSH server and postfix mail server which can be installed using the following command you have to configure the internet and set the system mail as follows here you have to set the system mail the required packages have now been installed in the next step we have to install gitlab and there are various methods to install it we can download a dbn package directly onto our systems so in order to download that you need to go to the official site and get the link directly based on your distribution so now let's just copy and paste it onto our terminal and hit enter after executing this command you'll have to navigate to the directory where it's stored and then install it as you can see the dbn package is available and you can install it using the following command now this might take about five minutes based on your system configuration and for installing it you need 4GB of ram at least so gitlab is partially installed as you can see here it's unable to detect a valid host name for your instance for this you have to convert a URL we're going to edit this file now and add your host name so after adding your host name just save and quit the file now you can start your gitlab instance by running the following command so as you can see over here the gitlab instance has been configured in this machine and you can now access it from the browser go to gitlab.com and create an account I've already created mine to do that all you have to do is fill in some information in the given field it contains nothing but your name email and a password check the first box which is the terms and conditions acceptance checkbox and also confirm that you are not a robot by any means click on the green register button and you're done this will send the confirmation mail to your email ID open it and confirm your gitlab sign up you can then sign in with your email and password to gitlab so here is what mine looks like so once you're logged into your account you should see something like this click on the new project button over here so we are going to create a very simple project the one from earlier just to demonstrate the basic functionality of gitlab so go ahead and click on new project and populate this field with something I'll type at Eureka Pipeline and right here below you have the possibility of selecting the visibility you can make it public if you want but I will leave it private because I'm just playing around so go ahead and create the project once you're ready you will have an empty repository like this there's nothing inside it so the first thing that we are going to do is create a new file the file will be called Master slash dot gitlab hyphen CI dot yml this is how the file should be named and this is the convention it will automatically recognize so I'll paste my pipeline code inside here and what we are trying to do here is to create three basic stages there is a build stage a test stage and a deploy stage in order to get something to run you need to Define some steps in each of these stages this is just to demonstrate that you can enter multiple commands one after another in a stage so now we have this file let's commit and see if the syntax that we have over here is valid now we're getting this message over here that says gitlab configuration is valid congrats now if you go to the project overview you will see here that something has started to build this is the icon that shows the pipeline has started and I did not need to configure anything in particular just by having this file here and no other files gitlab started building this pipeline as instructed and if I click on this icon I'll actually be able to see the pipeline how it looks within three stages now this will take a minute to start a Docker image and to actually execute it the first stage succeeded this goes down to the second stage now you will see that the second stage is running as well now let's see if the pipeline is successful you can easily see the pipelines that are currently running if you go on over here on the left panel and click on CI CD Pipelines you can see that the current pipeline is running the stage it's in and how much it still needs to be in order to complete now I just refresh the page and we see that it has run all the stages successfully foreign so what is branching nearly every VCS has some form of planting support branching means you diverge from the mean line of development and contribute to do work without messing with that Main Line in many VCS tool this is somewhat expensive process often requiring you to create a new copy of your source code directory which can take a long time for large projects some people refer to Grits branching model as its killer feature and it's certainly sets get a part in the VCS Community the way you get branches is incredibly lightweight making branching operations nearly instances nearest and switching back and forth between branches generally just as fast unlike many other VCS get anchorages workflows that branch and merge often even multiple times in a day understanding and mastering these features gives you a powerful and unique tool and I can entirely change the way that you develop so the mean another main difference is is that that developers can create their own branches and can work in parallel this keeps the main Master Branch free from the question because for example if this one is the master Branch then you can have two more branches Rocking In Parallel one can be the feature and other can be the bug fix one of the biggest advantages of get is its branching capabilities unlike centralized Version Control System get branches are cheap and easy to merge this facilitates the feature Branch workflow Which is popular with many git user the feature branches provide an isolated environment for every change to your code base and when a developer wants to start working on something no matter how big or small they create a new Branch this ensures that the past Branch always contains production quality code using feature branches as not only more reliable than directly editing production code but it also provides organizational benefits so in this example we have a master branch and then in between we created a test branch and later on created the feature branch because branches are lightweight and they are very fast switching back and forth so good branch is essentially an independent line of development you can take advantage of branching when working on new features or bug fixes because it isolates your work from that of other team members branches serve as an abstraction for the edit stage or commit process you can think of them as a way to request a brand new working directory staging area and project history when you want to add a new feature of fix a bug no matter how big or how small you spawn a new Branch to encapsulate your changes this makes it harder for unstable code to get merged into the main code base and gives you the chain chance to clean up your features history before merging it into Mains Branch default Branch name is master this is created by getting it Commander need repository we will pointer to a snapshot of your changes and it moves with the changes you commit so these are the branches operations we can create a new Branch or we can create and switch to the new Branch directly to create a new Branch we have to use grid branch and the branch name and to create and switch the new Branch with a single command we can use get checkout minus B and the new Branch 9. so let's try this if I'm in module 3 and if I check get Branch then I have three branches New Branch new Temp and temp if I create another Branch bug fix now let's create test let's stick to fuckfix then I'm still on Master Branch to use the bug fix I have to use choose get checkout bug fix now there is a simple way to create and switch to the branch at the same time and the command is so now what happened is we replace two commands with the one so command get branch name and the second command get checkout Branch name is replaced with get checkout minus P Branch name to list branches for a particular repository or to locate repository and click on the branches as highlighted so we already saw this but let's go back there again let's choose and depository let's take the most dual 3 only we click on the branch here and then you can see all the branches we have two branches remove branches master and nebron we can also check that using minus a option so we have two remote branches master and new branch and four local branches let's discuss the gets storage strategy so get does not store data as a series of chain sets or differences but instead as a series of snapshot when you make a comet get stores a commit object that contains pointer to the snapshot of the content use stage the subject also contains the author's name and email address the message that you type and pointers to the comment are commits that directly came from the comment it's parent opens zero parents for the initial commit one parent for normal Comet and multiple parents for Comet that results from a merge of two or more branches to visualize this let's assume that you have a directory containing three files and you stage them all and commit staging the files usually compute a checksum for each one is toasted version of file in the git repository and add stack checksum to the staging area so after staging two things are happening get confused this action and install each version of each file and adds to the stitching area when you create the comment by running the get comment get checksum each subdirectory in this case just the root project directory and store those three objects in the git repository git then creates a commit object that has the metadata and a pointer to the root project tree so it can recreate the snapshot when needed now get places only four types of objects in the object store the blobs trees commit syntax we already discussed them in the past module now these four Atomic objects form the foundation of gets higher level data structures first the blobs the each version of file is represented as a blob blob which is a contradiction of binary large object is a term that is commonly used in Computing to refer to some variable or file that can contain any data and whose internal structure is ignored by the program for each file there is one blob which stores the sha1 hash of the file content in it next come the trees we which represents one level of directory information that is a hierarchical structure which contains information about each of the blob it creates relationship between directories and the files in it next is the commit the commit objects holds the metadata for each change introduced into the repository including the author committer commit date and the log message each commit points to a tree object with all metadata next to the tags so we have not discussed tagging so far but tagging is generally used to capture a point in history that is used for marked version release such as v1.0.1 a tag is like a branch that does not change unlike branches tags after being created have no further history of comets now get suppose two type of tags annotated and the lightweight tags which differ in the amount of accompanying meta data they store a best practice is to consider annotated Taxes public and lightweight taxes private annotated tags to extra metadata such as Dragon name email and date this is important data for a public release lightweight tags are essentially bookmarks to a commit there are just a name and a pointer to a commit which is useful for creating quick links to level relevant comments now this is the storage strategy for object structure now if you see we have at the first level we have blocked where each file is represented as a blob next We have tree which contains content of directories and specifies files stored as blob so we have a tree which tree name we have a blob the hash and the file name and when we have comment which is a pointer containing the metadata and pointer to root 3 so the this is the commit ID then we have three which is Reid then we have author Steve committer Steve in the parent jb007 now our creating a new comment the new commit will store a pointer to the commit preceding error for example this so this is jb007 and the parent of this commit is this now the parent of this commit is this so this is Snapshot a b and c now how get internally manage these branches let's say you created a new Branch Testing using below command get Branch Testing this way create a new pointer to previous command the previous commit as this 0bi Y2 now git also keeps an additional pointer which is called as head so head will always point to the last commit of the branch for example if the branch we are on Branch Master then head will point to this now if we check out a new Branch Testing then head will move to the last commit of the test branch and when we make additional comets in the test Branch the head will move forward or the pointer will move forward so there are two types of branches local branch and a remote Branch local branch is a branch that only you that is the local user can see it exists only on your local machine and the command to create is get Branch at your branch name while the remote branch is a branch on a remote location in most cases are the default remote name is origin you can push the newly created local branch to origin now other users can track it and can see it so the default name from local branch that gets created when you run get init is the known as Master which is traditionally it is also known as trunk so let's quickly do a demo here let's go to Temp let's remove temp and let's go to tem oh mkdr10 I'm gonna do now now getting it into it now wait let me first remove it now I'm going to create a file into it touch file.txt now let's initialize get Branch coming there's some issue with my configuration ideally it gives you the branch but if I do get status I should get arm on Branch master so this is the default Branch I'm getting now I can create additional branches such as def feature and Bug these all constitute of branches created for the developer so that they can work thoroughly and independently on individual tasks without any inference now certain conventions are provided as best practices for example feature Branch can be name this feature bug branches bulk release branches release a remote branch on the other hand is local copy or the remote tracking Branch I should say is a local copy of a remote Branch when a branch is pushed to origin using the command a remote tracking Branch name origin slash Branch name is created on your machine this remote tracking Branch tracks the remote Branch you can update this remote tracking Branch to be in synced with the remote Branch using git fetch or get pull now let me show you what does the remote tracking branch mean if I go to module 3 so now this origin slash Master is my remote Branch I don't have a remote feature Branch feature is only a local branch if you see here this is just a local branch however this is a remote branch which has a remote tracking Branch origin Master now let's see the branches example so when a git clone command is executed how do we execute the git clone we just get the copy the remote URL we get the remote repository URL and then we perform the execute the command pet clone now when we do git clone then git will pull all data from the remote repository to my local which is remote repository to the local now git automatically names the Clone repository to origin this is the default and a pointer is created at the mass Master branch which is known as origin slash Master a local Master which is this is also created at the same position for local operations now switching between branches and different comments to switch to a particular Branch we already know how to clone it but before we move any further let's clone it again so I'm gonna remove the module 3. let's need the module 3 as it is okay I'm Gonna Leave the module 3 and I'm gonna clone it again so I'm gonna move into the audio and let's look at the branch we have one branch and the one remote tracking Branch so to create a branch what I can do is I can do get checkout buck another checkout sorry to switch between Branch we have to use git checkout Branch but before that let's create a branch I can use bug now and if I do great Branch then I am on Branch Park now I have created a bug Branch now there are few other options I can create a branch so the first one is I can create local branch from the head and can switch to it automatically so instead of creating get Branch I can use get checkout minus B let's call it feature so I have created a new branch and I have switched to it as well so in general get Branch Branch name and come on I should say yes and command get check out your branch name is equivalent to get checkout minus B Branch name now another one is we can create a new Branch from the commit hash so let's look at the commit hash now this is the commit hash so I can use a new branch and I'll so if I do get Branch I can see that I have a commit hash if I do grid log then I can see that that this branch is create the commutation is Created from this commit ID I can also create a branch from four for example for forehead prior to commit so the command is same so if I do get checkout minus B my Branch name had prior and then I do head four so this will be like this is the head then it will go like first of all let me go to master and if I do get log then I can see that I was unmastered only so let's create another minus B new Branch let's call it head prior and head root 4. so ideally if I do root 4 then this is like add one two three four this should be somewhere around here so it's switched so get log now if I do get logged then this is the fourth one two three four and this one as I said these are all different ways of creating a branch and switching between them so to switch to a particular Comet we need to use commit hash and commit hash is this for example if I want to switch to this one I can use git checkout and then the hash but when we do this our head will go in a detached site so we can look around make experiment and we can create a new Branch using minus P for example give checkout minus B and dash if I do get Branch now you can see this is there I can do git log and first check out master and if I do now get log I can see that detached is from this commit ID so commit hash is a generated sh1 hash for a particular comment and can't be changed until the user changes the comment details now we can also delete a branch this might be coming handy so for example they might be change scenarios when we spin a new Branch for example feature we merge it back onto the master so that it goes into production so feature Branch now for example has no use and can be discarded as it is already merged in the master so the way to do it is use the minus D option or minus capital D which is equal to force option so if there's unmerged branches we use minus D it's the merge branches we use smallly so let's get Branch first of all see the branches then and I do get Branch minus the park if I do get Branch now this is treated now the point here to note is that this has only deleted the local branch this is all not deleted the branches into the repository which is the remote Branch so how do we delete the remote Branch if I do get minus a branch minus a v c both the branches so we have only one branch so far so let's push one branch on let's push the bug feature branch on the remote this will ask for my credentials so now how can I delete this Branch so I can do like to delete a branch I can do get push minus D the remote name and the branch name here remote name as origin and the branch name is feature this will again Ask for credentials I strongly suggest you to use the passwordless SSS setup in the git now the remote branches get is been removed but only removed and now if you will see the features still access because this is on the local Rod another way to remove that is using get push the remote name call on the branch name for example let's push the feature again we are deleting it we're not pushing it so let's remove the minus D and let's push the feature again to remove it I can only do add colon here but before that let's first look at the branches so I have a feature branch and to delete it I just add cologne before and it will delete the branch for me next comes the merge conflicts so for a lot of people merge conflicts are as scary as accidentally formatting the hard drive a great thing about having get as your version control system is that it makes merging extremely easy and in most cases get will figure out how to integrate new changes however there are a handful of situations where you might have to step in and tell get what to do most notably this is when changing the same file even in this case git will most likely be able to figure out on its own but if two people change the same lines at the same file or if one person decided to delete it while other person decided to modify it get simply cannot know what is correct it will then Mark the file as having a conflict which you will have to solve before you can continue work so in this example we have this file and these both are modifying the same file and the same line the third line so this is this will create a merge conflict so much conflicts can occur on merging branches or when merging Force history together so merge conflicts are resolved manually by users git provides different merge tools to compare and choose the required changes which we will see in the coming slide or user can see use the third party merge tool with Git so let's look at the example that this is a file and in the master branch and we add some line in the master Branch again from the base Branch we create a new branch called feature one and we add another change in it so what happens is that when we merge these Branch with the master then we'll get a merge conflict so let's first create this example so I'm gonna go again and now if I look at the branches now let me remove the old branches which might confuse us and the head fryer as well right if I do the grid Branch then I have feature and master let's also remove the feature branch so get Branch minus D feature now let's edit the test.txt and let's remove it from base branch now let's add it to the staging area and commit it now let's create a new Branch feature one now that's the name is features plane now let's edit the test we are still on the master Branch so I'm gonna use right from Master branch now same I'll do again I'll add it and then I'll commit it with command test Master now let's check out to switch to the feature Branch change the same file and let's write from feature branch do the same things add it to stage area and commit it now get let's go back switch to the master Branch again now we already see that there is some point of conflict that will arrive but let's merge it the feature Branch to master now here we get a merge conflict right it says that we have a conflict in test.txt and we have to fix it and then we only we can commit so there are many ways available but the one quick way will be that we use some tool so what we're going to do we are introduce sum tool which is using kdf free and the command is git config we said we all we already discussed get conflicts in the past module as well so if you don't if you have any issues in them or if you are not sure what they are it's request you to go back to the previous module and just brush this up so we are setting a Global Contract we are only defining merge tool as kdf3 now once that is done we just run this command get merge tool and this will open us file and then we can select which merge we want to see and which not so here what we get is we get the total number of conflicts one number of automatic to solve complex zero number of Unsolved conflicts one so we have the base Branch we have the local branch and the remote Branch remote branches feature localized Master since we are on master and the basis the parent branch now we saw the base version this column as displayed here represent the changes which will be made in this area so we can go to the click on the letters and then it will enable us to see what we want to keep for example if I click on B if I click on a then no Source line if I click on B because there is no source source line the master hence we're getting this we are not updated we added a line if I click on B then I get from Master Branch if I click C then I get both if I remove B then I can keep only features let's keep the both and let's see if this file right now once that is done I can open my test.txt and look at this I can now commit it again let's look at the status I can commit it also have a look at the this file so this is how it will resolve the conflict in case there is no tool we are using so this line has no conflict from base Branch chance it is above then we have conflicts in this second line so where what is saying that at for the branch Mass head branch which is pointing to master this is the line from master and then we have the separator line and then we have the line from the feature branch which you're trying to merge from feature brought so we can do it manually how we can delete these lines and I can decide that I want to keep them both so I just do keep them both so let's now discuss about stashing first of all let's look at the requirements that fire station came into picture so often when you have been working on part of your projects things might be in a massive State and you might want to switch branches for a bit to work on something else the problem is you don't want to do a commit of half done work just so you can get back to this point later the answer to this issue is the get stash command the stashing takes the dirty state of your working directory that is your modified untracked files and stash changes and saves it on a stack of Unfinished changes that you can reapply at any time please note it does not considers the untracked files stashing stash the changes in dirty working directory but dirty we mean the work that is not completed yet and is in progress stashing command only takes the uncommitted changes it they might be in the staged area or they might be in the unstaged area but they are the track files so stash command flow is it records the current state of working directory and index it saves local uncommitted changes separately and reverse the working directory to had commit after this you will get a clean Branch once that is done you can reapply the stash changes again when you come to that Branch using stash pop or stash apply command and in case you don't want to apply any stash changes further you can just clear the stash so these are the changes for stash for stash to local changes by local we mean local branch we use the get stash command to list the modification stashed away by this command we can use the get stash list and to inspect or check the details we use git stash get show stash so let's look at this so we are going to continue using the audio 3 project so let's do get status so we have this untrack file and now I'm going to change the test.txt now I'm going to remove all this and say this is for stashing demo now if I do get status I can see that test.txt is modified at the same time let's also change some of the file let's change the readme.md this is for stashing I'm gonna put this readme.md to the staging area now so if I look the status we have one in the staging area one is an unstaged area and the last one is an untracked file if I look at the git Branch so I have feature branch and master branch and we are currently on feature if we for example let's first check out the try to check out the feature Branch there's a typo in my command so it does not allowing me to do a checkout of feature Branch why because I have changes in the staging area and it is asking me to commit my changes or stash them before I switch the branch so if I look at the branches again maybe I'm still on master and now I'm going to do git stash so I can now go ahead and change the branch and if I look the guest status then I only see the untracked files while the files which were unstaged area or which were in the staged area are not present let me revert back to the master branch now let's list the stash changes we have one stash which is this let's also show the changes in it so here is that we have a commit ID this is the commit ID and the merge the author name date and some other commands and now I can see the changes so I have two files one is the test.txt when I have removed these three files and if I do these status then let me pop it Dash pop so I have two modify files readme.md now the point here is that the files which are in the stage data for example readme.md was in staged area they now have been moved to the unstaged area when I do stash so this is the git status now I can apply them directly now I have to do git stash first of all let's look at the list no so let's stash this again and now let's do git stash apply so once I do apply I get the same thing if I do the guest status now now this is the demo that we just saw now at the same time I can use the get stash clear command as well so let's look at the different options that we have in the guest Dash so we have list show Drop Pop apply Branch clear create store we can use this different options for example list that we currently saw we also looked at this show pop apply I can create a branch as well starting from the committed with the stash was originally created I can remove all these stash entries using clear I can remove a single stash entry from the list of stash entry I can create a stash entry and I can store this Dash created via case Dash create these are some examples as well so you can check them in your workspace so what we're doing here is if you do the git status we can see that we have two files in the unstaged area the more readme.md and the pom.xml after stashing the changes no changes are left in the branch and guest status command shows that the branch is up to date now what we did is if we do the list then we already saw this when we did the get show then we see the difference is readme.md and it is pom.xml same as the case that we saw if we go back here right so we have test.txt I don't know why we are not seeing the readme.md maybe that was because it was in the unstaged area part if I do the git status now and if I remove this test.txt dot knowledge and if I do get stash now then let's do the git status so it is up to date if I do get star showstash then now I see the readme.md it was not displaying the read meter MD because it was in the staged area and moved to the other stage one we can apply the get stash using get stash apply but if you look at the status so far it is up to date but if I do get stash apply then we have moved these files in the unstaged area we can also use the get pop saying that we already saw [Music] so now let us take a look at the get basic commands so if you want to create repositories let's say you want to create your local repository you just have to initialize it using git init or if there is an existing repository you can use git clone if you want to make changes in your file you can use different commands you can use git status to see whether a file is there in your index or not you can use git add in order to add a file on your index and you can finally use git commit in order to commit those changes that you have made first thinking in repositories so you know that in git we deal with two repositories the Central and a local so you have to inform your local repository that which is your Center repository that basically lies on a remote machine so for that we add origin we add the link of the central repository using this command git remote at origin and then if you want to pull all the files that are in the existing Center repository user get pull and then finally if you want to reflect your changes into the center repository you can use git push for parallel development we have got git Branch it allows you to Branch off from your main branch and you can work on different features on a completely isolated Branch using git branch and then you can finally also merge all those changes in your production Deployable branch which is usually the master Branch using git merge and then we can also use git rebase now this is a special kind of merge so it's basically does the same thing as git merge only the comet workflow or the commit working tree looks a little bit different so you'll know about that because we'll be using rebase in today's session so now let us take a look at the git workflows so basically the git workflows can be categorized into broadly three kinds so there is the centralized workflow where there is one Central repository and only one working branch which is the master Branch then there is the feature Branch workflow where you have dedicated branches for each feature and then you've got git flow so we'll take a look at all of this and how to solve conflicts in each of these workflows so now let us talk about the centralized workflow so the centralized workflow uses a central repository to serve as a single point of entry for all changes to the project and there is only one default development branch and it is called the master and all changes are committed into this branch so this workflow does not require any branches besides the master so what the developers do they start by cloning the central repository into their local repository and in their low owned local copies of the project they will edit the files commit changes but you should know that these comments are stored locally they're completely isolated from the central repository and if the developers want the changes in the central repository they'll have to get push it so now let's say that we have got three people we have got Bob Alice and Jake and they are working on a project X so now let's say that Bob here makes the changes in the project commits it and then pushes it into the central repository so his changes will be published into the repository with his recent comments and now let's say that Alice is also working on the same thing and she wants to publish her changes in the central Repository but since Bob and Alice changed the same file in the same line there will be a conflict so let me show you how exactly does it happen and how to solve it so here I have created repositories for Bob and Alice so they're just in my system at different folders so since I have to show you the scenario I have to pretend to be two persons at one time so what I'll do I'll just click get bash here now I'm using git for Windows so you just don't have to do anything you just click bash here and will open up the git bash shell and the same thing I'm going to do for Alice over here time so let me just adjust the screens so that you can see what I'm doing in both of this get bash shells so I hope that you can see the screen over here so this is Bob's local repository shell that we're using and this is for Alice so the first thing that you need to do you need to initialize your repository so for that you have to use git init and I'll do the same thing for Alice it's done and now what I'm going to do I have already set up my central repository on GitHub so I'll just add the origin using git remote ad origin so I'll do that for Bob I'll use this command git remote at origin and now you need to provide the link of your central repository that is on GitHub so I'll just go to my GitHub so you can find the link over here so you just just copy it paste it and I'll do the same thing again for Alice all right so now there are files that are existing in my Center repository already so I want to pull those files so for that I'll just use this command git pull origin master so it has pulled all those files I'll do the same thing for Alice again so now if you see the repositories so this is Bob's repository it has pulled all the files from my simple repository and this is the dot get hidden folder this gets created when you initialize your repository specifically when we typed git init all right so now let us assume that Bob has made some changes so let's say this file over here so I'm just taking very simple examples so basically there will be code here just so that you can just understand the concepts of conflict I'm just using simple text files so let's say that Bob has made some change like this saved it and now Bob wants to commit these changes so first Bob will check the get status to see sorry so git status will show you whether a file has been added to the index or not so if it is in red it means that it has not been added to the index so for that we'll have to add this file so we'll use the command git add and the name of our file so now if you check get status so you can see that it is green now so it means that it has been added to the index it is there in the staging area and it is ready to be committed so now we'll use git commit in order to commit this and also remember that we have to commit using a message so for I'll just pause this Bob changing and Eureka so it is committed now Bob wants to push it to the center repository so I'll use git push Meridian master foreign and it's done so if you go to your central repository now so let me refresh this page so you can see Bob's comment over here so that means that this file has been changed in the central Repository so now let us go to Alice's local repository and let's say that Alice does not know that Bob has already made changes in the central repository and she's doing her work in her own local repository and she has changed the file something like this so we'll close it now Alice will also do the same thing she will add the file and then she will commit the file that Applause this flag m so let me just keep it simple I'll just write Alice over here and now she would want to push it the same way that Bob has done get push origin master and since it's a centralized workflow there is only the master branch so you can see that there is an error that is has been rejected the updates were rejected because the remote contains work that you do not have locally so it means that something was changed in the central repository which Alice's local repository doesn't contain and now it is centralized workflow and I don't want to mess around with my master Branch because my master branch is supposed to always be and a master branch is always supposed to keep the production Deployable code so instead of just pulling it directly I'll use rebase so what Freebase will do is that it will always have the initial commits that will come from the central repository it will just add up my commits on top of that workflow or my working tree that shows all my comments so I'll show how it works so for that I'll not just pull it directly I'll use a different command git pull free base origin master so it is showing that there is a conflict in the content and it is in edureka.txt and even this message doesn't appear and you're confused where the conflict is you can do one thing let me first clear the screen you can use git status to see where the conflicting file is so you can see that edureka.txt so in order to solve this conflict I'll use git merge tool so you can see it has opened up three files so this is the file that Bob has changed this is what was the original file and this is what Alice have changed right so Alice can take a look and this is the head where her initial commit right now points to so she can decide whether to keep the changes or not and let's say that Alice wants to edit it she wants to solve the conflict and let's say that she decides that she wants to keep both the two lines foreign save that file again save and exit save and exit save and exit all right so now you can continue rebasing so for that you can use this command okay let me clear my screen so that you can see what I'm typing so you can use this command git rebase continue so it has applied my last comment that I was trying to push it on to my central repository so now the merge conflict is solved and I should be in or let's say Alice should be successfully be able to push it to the central Repository so let's try it and the conflict is solved and it is successfully pushed onto the central repository so let me just show it to you so here is Alice's comment so this is how you deal with conflicts when you are using a centralized workflow so I hope that this is clear so now let us talk about the feature Branch workflow so if your team is comfortable with the centralized workflow but they want to streamline its collaboration efforts and it is definitely worth exploring the benefits of the feature Branch workflow so what happens here is that you dedicate an isolated Branch to each feature and because of this it is possible to initiate in-depth discussions around the new additions before you try to integrate them into the official project so the core idea behind this feature Branch workflow is that all feature development should take place in a dedicated Branch instead of the master branch and this encapsulation actually makes it easier for multiple developers to work on a particular feature without disturbing the main code base because again I'm telling you the master Branch should always contain production Deployable code so it also means that the master Branch will never contain broken code and this is going to be a huge Advantage when you're dealing with continuous integration environments so again let us consider the scenario so that this is a feature Branch workflow so they're all working on the features so let's say that Jake here is working on feature B and Alice and Bob are again working on feature a so again first Bob makes a new branch and he pushes that new Branch where he has added some features and it is pushed and he has pushed it into the central Repository and then again Alice wants to push it again the same things that she might have some changes that she might have done in the central Repository so then there is an advantage of using the pull request so pull requests are a way to initiate discussions around the branch so they give other developers the opportunity to sign off on a feature brush before it's get integrated into the official project so let me just show you an example of this again foreign so open up this repositories again so this is Bob's Repository so let's say that Bob wants to now Branch off and work on his new feature so he just can use this command over here get branch and let's say his feature is called feature one so now let's check out the feature one so now Bob is in the feature one branch so let's say he wants to add something all right so just save and exit and now again Bob wants to add this file all right you will come at this file comment done clear it for you and now you would want to push this Branch onto the central repository so for that you'll just use the same command git push origin and the name of his branch and this will actually create a different branch in the central repository with the same name and it will serve as a remote tracking branch and it is done so if you go to the center Repository now you can see that less than a minute ago there was a new Branch here which is called the feature one so if you go check out this branch in GitHub you can see it has got this file along with the other files because it was actually branched out from the master with the latest commit where it contained all the files right so now if Bob wants Alice to know that he has made some changes because now they're working in a featured Branch workflow so he will file a pull request so how to do that in GitHub you just have to go here just click this button you pull request the base should be Master branch and compare the feature one and then you can add some comments over here so you can just create and just let's say that please check it out so if you want reviews on your brand whether you have done or developed a feature in the correct way or not you can actually add reviewers here and you can you can actually also assign someone here so now since my GitHub only have me as a collaborator I don't have anyone else so so you can add other people who are actually contributing on to this Central repository and I find you can click this button oops all right there seems to be some internet issues with GitHub all right but the good part is that I'm actually done with that you don't have to do anything after you have created that pull request so what will happen after that is that whoever you add as a reviewer so they will either get a mail of how you set it up so they'll get a mail and then you can also comment and there will be a back and forth discussion about what to change or not and finally you have to merge it when it has been set so when you're all the when the entire I'm so sorry when your entire team is satisfied on the feature that you have worked on so someone will finally merge it onto the master branch so this was all about the feature branch so pull requests come in handy when to cat when you want to carry your discussions with your entire team so now let us talk about git flow so git flow workflow defines a strict branching model that is designed around the project release so this is somewhat more complicated than feature Branch workflow but this provides a robust framework for managing larger projects so this is what the entire branching model kind of looks like so you don't have to worry even though it looks very complex this workflow does not add any new Concepts or commands Beyond what's required for the feature Branch workflow instead the difference is that it assigns very specific roles to different branches and defines how and when they should interact so in addition to feature branches it uses individual branches for preparing maintaining and recording releases and of course you also get to leverage all the benefits of feature Branch workflow the pull requests the isolated experience experiments that you do on your feature branches and more efficient collaboration so how does it work so the git flow workflow uses a central repository as a communication hub for all developers just like all other workflows and the developers again work locally and push branches onto the central repository so the only difference is the brand structure of the project so instead of a single Master Branch so this workflow uses two branches to record the history of the project so the master Branch here actually stores the official release history and then develop branch that serves as an integration Branch for features and it is very convenient to tag all the commits in the master Branch as different versions so here you have tagged it as version 1.0 1.0.1 then 1.1.0 something like this so whatever naming scheme that you are comfortable with so you have got feature branches so there are two feature branches mostly so one is for that one is there which majorly focus on the coming release and the other needs to be worked on for a coming release or a future release so when a feature is complete it gets back it's get it gets merged back to the developed branch and feature Branch should never interact directly with the master so feature branches combined with developed brands for all intended purposes to the feature Branch workflow but the git workflow does not just stop there so once developers acquired enough features for a release or let's say a release date is coming up so what do you do you Fork a release Branch off to develop and creating this bronze start the next release cycle so no new features can be added at this point so you can only do bug fixes some hot fixes and patching up things and once it is ready to ship the release gets merged onto the master and tagged with the version number so this is how git flow works so obviously you'll also find merge conflicts here but it is very easy to fix because it is more on a structured way and when you have a lot of people working on a particular application especially larger applications you can use git flow for that and in most of the companies people use git flow so all you have to do you have to create feature branches you have to create a develop branch and you have to follow the git flow so just flow with the git flow [Music] so what is git rebase rebasing is the process of moving or combining a sequence of commits to a new base command rebasing is the most useful and easily visualized in the context of a feature branching workflow from a Content perspective if you look at the workflow rebasing is changing the base of your Branch from one commit to another making it appear as if you'd created your Branch from a different commit internally git accomplishes this by creating new comments and applying them to the specified base it's very important to understand that even though the branch looks the same it's composed of entirely new comments now the first thing to understand about git rebase is that it solves the same problem as git merge both of these commands are designed to integrate changes from one branch into another so why do we actually need rebase so let's take a look at why we need git rebase so consider what happens when you start working on a new feature in a dedicated Branch so then another team member updates the master Branch with new commits this results in a forked history which should be familiar to anyone who has used git as a collaboration tool the easiest option is to merge the master Branch into the feature Branch this creates a new merge commit in the feature branch that ties together the histories of both branches giving you a branch structure that looks like this now merging is nice because it's a non-destructive operation the existing branches are not changed in any way on the other hand this also means that the feature Branch will have an externus merge commit every time you need to incorporate Upstream changes if Master is very active this can pollute your feature branches history quite a bit while it's possible to mitigate the issue with Advanced git log options and it can make it hard for other developers to understand the history of the project so as an alternative to merging you can rebase the feature Branch onto Master Branch so this moves the entire feature Branch to begin on the tip of the master branch and effectively incorporating all of the new commits in master but instead of using a merge commit rebasing rewrites the project history by creating brand new comments for each commit in the original branch and the primary reason for rebasing is to maintain a linear project history for example consider a situation where the master branch has progressed since you started working on a feature Branch you want to get the latest updates to the master branch in your feature Branch but you want to keep your branches history clean so it appears as if you have been working of the latest Master branch this gives the latter benefit of a clean merge of your feature Branch back into the master Branch so why do we need or why do we want to maintain a clean history the benefits of having a clean history become tangible when performing git operations to investigate the introduction of a regression hence rebasing hair onto the master Branch facilitates a fast forward merge and rebasing is a common way to integrate Upstream changes into your local repository pulling in Upstream changes with Git merge results in a super flush merge commit every time you want to see how the project has progressed on the other hand rebasing is like saying I want to base my changes on what everybody has already done one golden Rune however is that you must never rebase public history you should never rebase comments once they have been pushed to the public repository the rebase would replace the old comments with the new ones and it would look like that part of your project history abruptly vanished for example think about what would happen if your eBay is Master onto your feature Branch the rebase moves all of the commits and master onto the tip of the feature the problem is that this only happened in your Repository all of the other developers are still working with the original Master since rebasing results in brand new comments git will think that your master Branch's history has diverged from everybody else's and the only way to synchronize the two Master branches is to merge them back together resulting in an extra merge commit and two sets of commits that contain the same changes and the original ones are the ones from your rebased branch needless to say this is a very confusing situation so before you run git rebase always ask yourself is anyone else looking at this branch if the answer is yes take your hands off the keyboard and start thinking about a non-destructive way to make your changes for example the get reward command otherwise you're safe to rewrite history as much as you like so now let's run a few rebase commands and see how they work so firstly let's go to this VM I have whipped up and I have already branched out my base and we have made some changes to our Branch using the git Branch command let's call it edureka Branch now let's check out from here and we can see all of our previous commits also are actually available in this new branch now you can see that this one is my master branch and this one is my new branch and all the commits in both the branches and add a new text file here and we're going to call it as branch now let's move on guys and we're gonna rebase now so to rebase our Branch to master we use git rebase master with that you can see how under the new Branch or the new Master Branch you can see all of the changes you have made in the rebased branch which is Eddie Rica Branch now that was the standard rebase let's see how we can do the same using the interactive rebase running git rebase with the iPhone I flag begins an interactive rebasing session instead of blindly moving all of the commits to the new base interactive rebasing gives you the opportunity to order individual commits in the process and this lets you clean up the history by removing splitting and altering an existing series of commits it's like git commit amend on steroids so to rebase our Branch to master we use git rebase hyphen I and this rebases the current Branch onto the base which is our Master but uses an interactive rebasing session so this opens an editor where you can enter commands for each commit to be rebased these commands determine how individual comments will be transferred to the new base and you can also reorder the commit listing to change the order of the commit themselves and once you have specified commands for each commit in the rebase git will begin playing back commits applying the rebase commands interactive rebasing gives you complete control over what your project history looks like this affords a lot of freedom to developers as it lets them commit a messy history while they're focused on writing code then go back and clean it up after the fact most developers like to use an interactive rebase to polish a feature Branch before merging it into the main code base this gives them the opportunity to squash insignificant comments delete obsolete ones and make sure everything else is in order before committing to the official project history to everybody else it will look like the entire feature was developed in a single series of well-planned commits the real power of interactive rebasing can be seen in the history of the resulting Mass Branch to everybody else it looks like you're a brilliant developer who implemented the new feature with the perfect amount of commits the first time around this is how interactive rebasing can keep a Project's history clean and meaningful and rebasing can be used to change older and multiple comments committed files and multiple messages while these are the most common applications git rebase has additional command options that can be useful in more complex applications which is git rebase d means during playback the commit will be discarded from the final combined commit block then we have get rebase P which leaves the commit as is it will not modify the commits message or content and will still be an individual comment in the branches history then we have git rebase X and during playback executes a command line shell script on each marked commit a useful example would be to run your code basis test Suite on specific comments which may help identify regressions during a rebase now let's talk about the configuration options as well so there are a few rebase properties that can be set using git config and these options will alter the get rebase output look and feel so dbase dot stat a Boolean that is set to false by default the option toggles display of visual diff start content that shows what change since the last dbase and then we have rebase dot Auto squash which is a Boolean value that toggles the Auto's cost behavior and then we have a rebase DOT missing commits check which can be set to multiple values which change rebase Behavior around missing comments and we have one which prints uh warning output in interactive mode which wants of remove comments then we have error which stops the rebase and prints a removed commit warning messages and then we have ignore which is said by default this actually ignores any missing commit warnings then we have a rebased or instruction format which is a git log format string that will be used for formatting interactive rebase display now let's move on guys and talk about the pitfalls of rebase so one caveat to consider when working with Git rebase is merge conflicts may become more frequent during a rebase workflow so this occurs if you have a long lived branch that has trade from the master eventually you will want to rebase against master and at that time it may contain many new comments that your branch changes May conflicts with this is easily remedied by rebasing your branch frequently against master and making more frequent comments the continue and about command line arguments can be passed to get rebase to advance or reset the rebase when dealing with conflicts a more serious rebase caveat is lost commits from interactive history rewriting running rebase in interactive mode and executing subcommands like squash or drop will remove commits from your Branch's immediate log at first glance this can appear as though the commits are permanently gone using git ref log these commits can be restored and the entire rebase can be undone git rebase itself is not seriously dangerous the real danger case arise when executing it and that's all you really need to know and start rebasing your branches if you would prefer a clean linear history free of unnecessary merge you should reach for git rebase when integrating changes from another Branch it's a perfectly valid option [Music] let us understand the advantages and disadvantages of merge and rebase first we'll discuss the advantages of merge traceability traceability helps keeping information about the historical existence of a feature branch and groups together all commits part of that particular feature there are a few disadvantages so in March history can become intensely polluted by lots and lots of merge comments also debugging using get bicycle become much harder due to the merge commits now that we've learned the disadvantages and advantages of get much let's discuss the pros and cons of kitry Base so the advantages are code history always remains flat and readable in gitry base clean clear commit messages are as much part of the documentation of your code base as code comments comments on your issue tracker Etc also manipulating a single commit is extremely easy that is you can revert them back very easily there are a few disadvantages squashing the feature down to a handful of commits can eventually hide context unless you keep around the entire historical Branch with the development history also rebasing does not really play well with pull requests this is because you cannot see what minor changes someone made if they have repaced rebasing can sometimes be extremely dangerous rewriting history of shared branches is prone to teamwork breakage this can be mitigated by doing the rebase on a copy of the feature Branch but rebase carries the implication that competence and carefulness must be employed the last disadvantage is that rebase sometimes requires a little more extra work using rebase to keep your feature Branch updated requires that you resolve similar conflicts again and again yes you can reuse recorded resolution sometimes but merge wins here just solve the conflicts one time and you're set moving on we'll discuss when to really use both of these commands now if you want to see the history completely the same as it has happened you should always use much merge preserves history where SG based rewrites it get merge as a default behavior when you use gitbull use it as a default if you're not bothering about comment history and want to avoid further problems learn to use merge when you're always working with the big team now moving on let us understand when we can use rebase rebasing is better to streamline a complex history here you are able to change the comment history by using interactive replays that is hyphen I you can remove undesired commits squash two or more commits into one or edit the commit message you can also use get rebase for creating temporary local branches they are not necessary for public comment history and won't create any further problems and as I've already mentioned before you can use gitry based hyphen I that is interactive for rewriting your local comment history into a pretty one before pushing it on to a remote server your remote server can be gitlab GitHub anything of that sort now if the feature Branch you're getting changes from is shared with other developers freebasing is usually not recommended because rebasing process will create inconsistent repositories for individuals rebasing makes a lot more sense that is if you're working alone or on a small team make it a habit to use rebase now moving on let us discuss the similarities between merge and replays there is only one similarity that is both of these commands can be used to combine two different branches I'm sure by now you must be pretty aware of that since there is only one similarity between both of them let us understand the differences between merge and rebase and how each of them use different techniques to combine two branches so as I've already mentioned before git merge is a git command that allows taking the independent lines of development that get Branch created and then eventually integrate them into a single branch on the other hand rebase is a git command that moves or combines a sequence of commets to a new base Comet that provides easy visualization of feature branching workflow so rebase has only one line of development or one line of work but merge on the other hand has several different lines of development so rebase provides easy visualization or feature branching workflow thus this is the main difference between get merge and get gbase as you can see the syntax of merge you have firstly two lines that is git checkout feature and the second line that says get merge Master you can use the checkout keyword to switch branches and I am switching from my feature Branch currently I'm working on my feature branch and I want to switch to my master Branch so I'm using the line git checkout feature the second line that says get merge Master allows me to merge the contents of my feature Branch into my master Branch or you can also execute this entire command in one line that is get much feature Master on the right hand side you can see the rebase syntax here also it's similar to the one as much there is one line that says git checkout feature and the second line that says get rebase hyphen Eye Master and as I've already mentioned before use git rebase hyphen I that is interactive for rewriting your local commit history into a good one before pushing it onto your remote server so that is why we use hyphen I and the rebase keyword is used to execute rebacing I hope both of these differences are clear now let's look at the intricate details and the differences between git merge and get tree base the first difference is based on the project history rebase provides a much cleaner project history than git merge I'm pretty sure you're clear of that by now the second difference is navigation it is easier to navigate through the project and rebase than it is in get March the third difference is the number of steps merge is a one-step operation with one place to resolve conflicts and the comments that we reachable from the branch always remain reachable rebase on the other hand is a multi-step operation here there are more steps but each of these steps are comparatively small the last difference is the context in git match the developer can see when the Upstream changes were incorporated into the feature on the other hand in rebase the developer cannot see when the Upstream changes were incorporated into the feature hence this is also a difference between get merge and get tree base moving on to the last part of the session which one is better for which situation both merge and rebase can be used to combine two branches much command just unifies your work with the commit without changing history while rebase apply feature brand changes on top of the master branch and change the entire history if you prefer to have a clean history then you can always choose GPS if you need to preserve the history changes then merge would definitely be the best choice if you and your team are not familiar with or do not understand the intricacies of Freebase then you probably shouldn't use it in this context always merge as the safest option but if you and your team are extremely familiar with both of these options then the main decision revolves around this do you value more a clean linear history or the traceability of your branches in the first case go for a rebase policy in the latter go for the merge one foreign [Music] so Jenkins is an open source automation tool written in Java with plugins built for continuous integration purpose Jenkins is used to build and test your software projects continuously making it easier for developers to integrate changes to the project and also making it easier for the users to obtain a fresh build it also allows you to continuously deliver your software by integrating with a large number of testing and deployment Technologies with Jenkins organizations can accelerate the software development process through automation Jenkins integrates development life cycle processes of all kinds including build document test package stage deploy static analysis and much more Jenkins achieves continuous integration with the help of plugins plugins allow the integration of various devops stages if you want to integrate a particular tool you just need to install the plugins that are required for that tool for example the various plugins that are supported by Jenkins include get Maven 2 project Amazon ec2 HTML publisher and so on so this was the definition of git now if you talk about the advantages of git as already discussed it is an open source tool and it has a great Community Support it is very much easy to install and almost has 1000 plus plugins to ease your work if a plugin does not exist you can code it and share it with the community it is free of cost and it is built with Java and hence it is portable to all the major platforms so this was all about the Jenkins now let us talk about why should we integrate git with Jenkins or why they are used together so as already discussed git is a source control manager and that's where you keep your source code for tracking all the code changes that happen over the time and to Baseline the versions when they are ready for release Jenkins on the other hand is a continuous integration solution it was devised to automate most of the tasks that a developer has to do while developing a new application without a CI solution a developer has to spend much time doing these repetitive non-productive tasks so let us take an example of a new feature in a web application so what happens here is a developer will be identified and assigned the task so he takes the existing code base from the source code say for example git makes its changes carries out unit testing and shows the code quality manually and checks the new code back into the git then he has to build the code deploy it into the integration instance run integration testing and once the change seems satisfactory he raises a request for production deployment now if we only had a minion to take care of this testing building quality checks and deployment sections the poor developer could have focused better on the stuff that is really good at that is implementing and improving the features logic so this minion is nothing but Jenkins it acts as an orchestrator which runs all of these activities once the change is checked into the source control and thus gives a quick feedback to the developer whether the changes he has made are good enough for the production deployment or not so Jenkins is extremely flexible open source and has a lot of plugins that can do almost anything that you wish to so these were the reasons of using Gateway Jenkins now next comes the question of how do they work together so here I'll be showing you one demo and these are the steps that are covered in this demo so first we create a sample program so you can create any program that you want be it a Python program or a Java program or any other program then in the second step we create a Jenkins job and once we create the Jenkins job we add the program that is created in the first step to the GitHub so for that we create a GitHub repository a public GitHub repository then upload the code on that repository using git and in The Next Step you add git plugin in Jenkins and finally we configure the Jenkins job based on the GitHub repository so let me just show you how do you do this so what we need to do here is we have to create a directory on your desktop and you have to create one python file here so the name of the file is say for example anything that you want on in this case I've written my file okay so this is basically a simple python file with a very simple code print hello world that's it so what we need to do here is you can open your git bash here so first let us initialize an entry get repository here using the command get init it's an empty repository has been initialized here in this demo folder so now let us just check the status here using the command get status so as you can see here this file it is in red color my file.pri so red color means here that it has not been added so just to add the file you can use the command get add and the dot you can also specify the name of the file here like my file.view app but if there are multiple files that you need to add then you can use the dot symbol so the file has been added and now let us just verify this okay so as you can see here previously it was red and now it is green here so after adding the file now let us just commit these changes for that the command is get commit hyphen M any message if you want add my file dot field so we have now committed this changes so what we need to do here is we have to push this my file.py on the GitHub repository so for that let me just go to my GitHub account okay okay guys so what we need to do here is we have to create a public repository for that you have to click on this repositories on your GitHub main page and you have to click on new so once you click on new you can name the repository say for example git Jenkins integration or whatever name that you want and the description is optional here and if you want you can initialize this repository with the readme and click on create Repository so this has been created here so guys now we have created a public repository on GitHub and now our task is to upload this file called myfile.pivac onto the public repository on GitHub for that we will have to first connect to it and the command for that is get remote add origin and the link of that repository and how do you get that link so when you create this repository here you get the link okay so just copy it and paste it here so this has been added and now we can push our content there so for that the command is git push hyphen U origin and master here you can see if you just refresh this page okay so my file dot py here it has been added onto our public repository on GitHub so now what our job is we have to create a Jenkins job first login onto your Jenkins homepage enter the username and the password so now what we'll do here is we will create here a new job Jenkins get demo and choose the freestyle project click on OK see here what you need to specify the source code Management in the source code management okay before that you have to download the get plugin so how do you do that go to manage Jenkins here as you can see left hand click on manage plugins okay if you already have git plugin installed on your Jenkins you can click on installed here so if it is already downloaded yeah as you can see here on my system it has already been downloaded you can find it here else if it is not available like if it is not installed you can click on available search here by typing git and download so this is how you download the get plugin and going back to our project let us just configure this now okay so this was a project that we created Jenkins git demo so let us just configure this project so in the source code management section here you must click on get and you enter the git repository here copy this this link and you paste it here click on apply it has been added and here in the build trigger section we have to click on pole sem so here we have to enter the Chrome expression periodic scheduling of Jenkins job is done through pole sem so what you need to do here is in my case I'm typing here five Asterix separated by space I hope you guys are aware of the cron syntax so five asterisks here mean that our Jenkins job will run every single minute so every single minute our Jenkins job will check for the source code change if there is any change it will run like it will build the job it will build the code this is the meaning of that click on apply yeah and now since we have a python code so what we will do here we will add a build step since guys I'm using your Windows operating system so I'm clicking on execute Windows batch command if you are using Linux or Mac OS you can execute shell script okay so click on here so since I have a python code there so I will type python like the command to run the python file my file dot UI okay fair enough click on apply save so now we will build this project okay as you can see here our build was successful so this was the hello world thing that we had written in our program and here it shows success okay so now what we will try to do is we will do some changes there in the my file we will add a few lines and then we will see what happens Ctrl C say for example hello world now we will say how are you save it okay so now we have to push these changes onto the public repository of GitHub so we will do that through git so now let's check the status first okay so modified as you can see here the file has been modified and that has been shown here so for that we will first add now let's check the status so now we will commit this file some message if you want modified my file press enter so now we have to push these changes so for that the command is get push hyphen U origin master so these changes have been pushed onto the GitHub account so let me just refresh this page okay so as you can see here modified my file this was the commit message that we had written so our changes have been reflected here if you can see here print how are you we had added this line if you remember so now we will see what happens to Jenkins now so here we will click on build now so if you click on Console output here okay started by an SCM change so since there was change in the source code that triggered the Jenkins job so here you can see Hello World and how are you both the lines have been displayed here and it is success [Music] foreign so first of all what is a web hook now the concept of a web hooker is very simple it is an HTTP callback an HTTP post which occurs when something happens through a simple event notification via HTTP post to make it simple GitHub will perform a post request with a payload object which contains data about the triggered event to your Divine webhook URL so upon triggering this event it will allow us to automate the executions of some actions based on your GitHub events for example if after each push to the master Branch we want to package or deploy our software we can simply add a web hook to the Jenkins task responsible for packaging or deploying the service so GitHub webhooks and Jenkins are used to trigger the build whenever a developer commits something to the master branch so at least let's first look out in theory let's see how to add build a web hook in GitHub and then add this webhook in Jenkins so first we go to our project repository and head straight to the settings on the right corner we're going to select the option of web Hooks and click on ADD webworks here we have an open field for payload URL where we are going to put in our Jenkins address followed by a GitHub hyphen webhook extension this payload URL is the URL where our Jenkins is running and we are adding GitHub Dash web hook to tell GitHub that it is a webhook plain and simple next we have content type so here we are basically trying to specify what kind of data we want in our web hook we are going to select Json data next we have Secret in this field we are going to secure our web hook so we can provide a secret in our webhook and ensure that only applications having this webhook can use it and then we have SSL verification this SSL Checker will help you diagnose problems with your SSL certificate installation you can verify the SSL certificate on your web server to make sure that it is correctly installed valid trusted and doesn't give any errors to any of your users now which events would you like to trigger this webhook in this you particularly have three options now if you want only to send data when someone pushed into your repository you use the just the push event same thing but if you want somebody to get notified whether there is a push or a pull event you select send me everything and finally you have let me select individual events in which you can configure for what events you want your data and then click create and a webhook will be successfully created in my case I will be using the IP address where my Jenkins is running now here is a problem you have to take care of if you're running Jenkins on localhost then switching your IP for localhost will not work because webhooks can only work when they are exposed to the internet in such a case you want to make your localhost 8080 exposed to the internet and you can use various tools such as ngrok in cases like these now let's see how to use this webhook in Jenkins so next you want to log into Jenkins and create a new item or a new job here you can click on the kind of project you would like it to be and under source code management you're going to select the option git and put in your repository URL in the given field then in build triggers you want to select the GitHub hook trigger forget sem polling and save your changes now when you make any updates in this particular git repository you will get an update on your Jenkins show and in this way we can add our web hook to our job and ensure that every time a developer commits code to GitHub our build will be triggered now that we've done it theoretically let's go ahead move on with our demonstration so this is my GitHub repository opened up I'm using the virtual machine to run this on Ubuntu so this is a demo repository and here I'll go to settings select webhooks and add a web hook then I'm gonna go to my Jenkins and select the URL so it's going to start out with your regular HTTP colon slash slash your IP address and your port number after the final slash you're going to type in GitHub webhook and don't forget to end it with a slash next in content type we are going to be using application or a Json file I am not going to keep any secret or anything and in events I'm just going to keep just the push event you can go ahead and use any of the others this is just for demo purposes hence we're just going to keep it simple then I'm going to add the web hook then you'll get a message like this which says okay that hook was successfully created so you know your hook is created like I said if this doesn't work you can use something like my public IP or an ngrok to make this run okay next let's move on to Jenkins and create a new job so we're going to start here and create a new job let's call it webhook1 I'm going to select the freestyle project and click on OK all right so under source code management I'm going to select get I'm going to select the link of my repository and put it right here now the condition is whenever a change happens in this repository I want my Jenkins to be automatically triggered right so I'll select build triggers and here I'm going to select GitHub hook trigger for git SCM polling so this job basically will listen for triggers from this particular repository yes all right scroll down let's apply and Save so now let's go back to our GitHub and try to make some changes in our sample file let's just type some Demi text for Jenkins and comment changes and if you go down now you can see this has automatically been triggered the whole idea of this is GitHub should basically send a notification to Jenkins that there has been a new comment pushed to that particular repository using the web hook that we've just created okay and that is how we integrate a Jenkins job with webhooks in GitHub [Music] why git Ops previously companies usually had separate operations and development teams and unfortunately they did not talk to each other too much luckily we have devops which tries to address this by ensuring increased collaboration so that operations and development teams work closely together in an Ideal World it meant that you have the same people who are both writing the applications and operating the applications it means automating as much as possible to reduce the need for manual human input when operating applications so devops was a cultural change now with Git Ops it takes it to the next level where teams have an operating model where they not only Define the infrastructure as code but also make deployments and changes to infrastructure s code by submitting pull requests that people can eventually review and approve collectively with githubs you make it ubic wishes to have continued is integration on a continuous delivery server when deploying your application now once you submit a change the server will pick it up immediately pull the changes execute any automatic tests execute any quality checks and eventually build the artifact this artifact is then published to an artifact repository and eventually deployed to infrastructure by applying git Ops there is a source of Truth for both your infrastructure and application code allowing development teams to increase velocity and eventually improve system reliability with all of this said what exactly is git Ops on the surface it is quite simple git Ops is centered around using a Version Control System such as git to house all information documentation and code for a cluster deployment and then use automated directors to deploy changes to the cluster however once you dig past the surface you discover that far more complex than that git Ops is the operational practice which users get as a single source of Truth it is to be noted that Source control repository on get becomes the source of truth and not the actual servers or the Clusters this is nothing but having your infrastructure as a code which means all your infrastructure setup is inside a code base it also includes the automation of deployments rollbacks and much more git repository can be leveraged for version controlling system peer reviewing system automating and deploying process for the production environment using git itself developers are now doing continuous delivery and automated pipelines additionally the web hooks from the git can be leveraged to push these configurations into the development and test environments so once you merge that particular pull request onto the main branch the deployment to production eventually happens on the other hand get Ops also allows automating everything using pipelines and deploying that to production once you merge the code into your production Branch it is called get Ops because all the configurations are managed in the get repository many developers deploy the infrastructure code as well as a part of the automation process by using only one repository for an application or a service and have a separate repository for each of them now let's say you have three environments namely development test and production there should also be three branches that are named the same that is development test and production this is done to map each of these branches to different environments in the kubernetes cluster once you push the changes onto that particular Branch there will be a relevant automated pipeline which will be eventually set up this means that whenever there is a change for that specific Branch the pipeline deploys to that environment it also identity defies tests and verifies that the environment looks all right this way when a developer makes a change in their development branch and once the development Branch succeeds they will eventually be able to merge pull requests in order to join it to the production branch and once you click on merge that is when it will all deploy to the production environment if you want to do a rollback you can simply create another pull request to roll back to that particular previous state of the branch so if a user goes and changes the code in the git repository it creates a container image and that container image is pushed to the container registry which is eventually updated into a config updater once you create a pull request to merge to a different branch that is when it deploys to the concern branch and then it tests whether these are good this way every time you raise a pull request you know what you're merging and that pull request is being reviewed by somebody based on the success criteria of that particular automated Branch pipeline this is how git Ops helps teams in solving the automation problem thus githubs can be summarized as these two things the first one is that it is a path towards a developer experience for managing applications where end-to-end CI CD pipelines and git workflows are applied to both operations and development the second one is that it is an operating model for kubernetes and other Cloud native Technologies providing a set of best practices that unify deployment management and monitoring for containerized clusters and applications git Ops is based off of four main principles so to start managing your cluster with Git Ops workflows the following must be in place the first one is that the entire system described declaratively kubernetes is just one example of many modern Cloud native tools that are declarative and that can be treated as code declarative means that configuration is guaranteed by a set of facts instead of by a set of instructions with your applications declarations versionized in get you have a single source of Truth your applications can then easily be deployed and roll back to and from kubernetes and even more importantly when disaster strikes your clusters infrastructure can also be dependably and quickly reproduced the second one is the canonical design System state versionized in git with the Declaration of your system stored in a version control system and serving as your canonical source of Truth you have a single place from which everything is derived and driven this trivializes rollbacks where you can use a git River to go back to your previous application state with git's excellent security guarantees you can also use your SSH key to sign commits that eventually enforce strong security guarantees about the authorship and province of your code the third one is approved changes that can be automatically applied to the system once you have the declared State Captain get the next step is to allow any changes to that system to be automatically applied to your system What's significant about this is that you do not need cluster credentials to make a change to your system with Git Ops there is a segregated environment of which the state definition lives outside this allows you to separate what you do and how you're going to do it the fourth and the last principle is that software agents to ensure correctness and alert on Divergence once the state of your system is declared and kept under Version Control software agents can inform you whenever reality does not match your expectations the use of Agents also ensures that your entire system is self-healing and by self-healing we do not just mean when nodes or pods fail those are handled by kubernetes but in a broader sense like in the case of human error in this case software agents act as the feedback and control Loop for your operations now I assume all of you have a fair idea of what git Ops is moving on we'll discuss how it works so how does git Ops work it's pretty complicated but let's try and understand this in a simple way imagine you have every single piece of documentation all of your yml files and every bit of necessary code required for kubernetes contained in a single git repository with the help of a few automation tools anyone who is tasked with managing that kubernetes deployment can do a pull request edit the code and and then eventually issue a merge request to the git repository so once the merge request is complete the automated git Ops operator detects something has changed another automator declares the changes operational and the change is then automatically deployed to the cluster so basically the two important things you need to know the first one is that changes are made by a pull request operating via pull request reduces the number of variables which eventually transform deployments into crime scenes fortunately code deployers are no longer awarded what hero status for manually moving bits from point A to point B the second thing is that convergence ensures eventual consistency if a group of configuration updates is made by a human they observe state in the cluster can drift from the desired State declared in get thus causing Divergence when the desired and observed states are different kubernetes provides a convergence mechanism to dry have the observed State towards what the teams declared as a desired state in Version Control now let's discuss a typical developer workflow for creating or updating a feature a pull request for a new feature is pushed to GitHub for review the code is reviewed and approved by a colleague so after the code is revised and reapproved it is merged to get the git merge eventually triggers The Continuous integration and build pipeline it runs a series of tests and eventually builds a new image and deposits this new image to a registry the deployment automator watches the image registry notices the image pulls the new image from the registry and updates its yml in the config repository the deployment synchronizer which is installed to the cluster detects that the cluster is out of date it pulls the change manifest from the config repository and deploys the new feature to production so in this workflow that I just talked about automation is extremely crucial so as to keep everything moving with the level of efficiency that cannot be matched with purely manual Administration the git opscore Machinery is in its CI CD tooling with the critical piece being continuous deployment that eventually supports git cluster synchronization so now we'll move on and talk about the benefits of applying git Ops best practices the first one is increase productivity continuous deployment automation with an integrated feedback control Loop speeds up mean time to deployment your team can ship 30 to 100 times more changes per day increasing overall development output by almost 2-3 times the second reason is enhanced developer experience push code and not containers developers can use familiar tools like get to manage updates and features to kubernetes more rapidly without having to know the internal of kubernetes newly onboarded developers can get quickly up up to speed and be productive within days instead of months the third benefit is improved stability when you use git workflows to manage your cluster you automatically gain a convenient audit log of all cluster changes outside of kubernetes an audit Isle of who did what and when to your cluster can be used to meet foc2 compilence and ensure stability the fourth benefit is higher reliability with git's capability to revert or roll back and Fork you gain stable and reproducible rollbacks because your entire system is described in git you also have a single source of truth from which to recover after a meltdown reducing your meal time to recover from hours to minutes the fifth benefit is consistency and standardization because git Ops provides one model for making infrastructure applications and kubernetes add-on changes you have consistent end-to-end workflows across your entire organization not only are you continuous integration and continuous deployment pipelines all driven by pull request but your operations tasks are also fully reproducible through git the last and most important benefit is stronger security guarantees get strong correctness and security guarantees backed by the strong cryptography used to track and manage changes as well as the ability to sign changes to prove authorship and origin is key to a secure definition of the desired state of the cluster let us begin with our first topic that is the basic level of or the beginner level of interview questions so the first question is what is git git is a distributed Version Control System it lets you track changes made to a file and allows you to revert back to any particular change that you wish to it is a distributed architecture that provides many advantages over other version control systems like the SVN one of the major advantage is that it does not rely on a central server to store all the versions of our project's files so what happens in gitis instead every developer clones a copy of a repository as you can see in this diagram and he has the full history of the project available on his hard drive so whenever there is a server outage all you need to do is just copy one of your teammates locally get repository and bang you have the code on your system so there is one Central Cloud repository where the developers can commit changes and share them with the other team members so this is what git is in nutshell so the next question is what is a distributed version control system so these are the systems that don't rely on a central server to store a project file and all its versions you can see the diagram that is on your slide right now in a distributed Version Control System every contributor can get a local copy or a clone of the main repository here every programmer can maintain a local repository which is actually the copy or the clone of the central repository which is present on their hard drive so developers can commit and update the local repository without any hassles with an operation called pool they can update their local repositories with the new data from the central server and pull operation effects changes to the main repository from their local Repository the next question is what are the advantages of using a Version Control System so with Version Control System all the team members are allowed to work freely on any file at any given time Version Control System gives you the flexibility to merge all the changes into a common version all the previous versions and variants are neatly packed up inside the version control system or the VCS you can request any version at any time as per your requirement and you'll have a snapshot of the complete project right at your hand so whenever you save a new version of your project your VCS requires you to provide a short description of the changes that you have made Additionally you can see what changes are made in the files content this helps you know what changes have been made in the project and by whom finally a distributed Version Control System like git allows the team members to have a complete history of the project so that if there is a breakdown in the central server you can use any of your teammates local git Repository so these were a few advantages of using the Version Control System the next question is what is the difference between get and SVN so git is a decentralized Version Control tool whereas SVN is a centralized Version Control tool git belongs to the third generation of the Version Control tools whereas SVN belongs to the second generation of the Version Control tools so what happens in git is clients can clone entire repositories on their local systems whereas in SVN version history is stored on the server side of the repository in git commits are possible even if you are offline whereas in SVN only online commits are allowed so in git the push and pull operations are comparatively faster whereas in svan the push-pull operations are comparatively slower git works are shared automatically by commit command whereas in SVN nothing is shared automatically so these were a few differences that you can mention in this question okay so the next question is what is the difference between git and GitHub so as we have already seen git is a version control system of distributed nature that is used to track changes in the source code during software development so get AIDS in coordinating work among programmers but it can be used to track changes in any set of files so the main objectives of get are speed data Integrity support for distributed non-linear workflows whereas GitHub is a git repository hosting service plus it adds many of its own features so GitHub provides a web-based graphical interface it also provides access control and several collaboration features basic task management tools for every project so the next question is what language is used in git so here instead of just telling the name of the language you should also mention the reason for using this language as well so git uses C language git is a fast and C language makes this possible by reducing the overhead of run times associated with high level languages the next question is mention the various git repository hosting functions the following are the main gate repository hosting functions as you can see on the slide GitHub gitlab bitbucket Source force and get Enterprise and as per my opinion the GitHub is the most popular among these options so the next question is what is a repository in git so repository in git is a place where git stores all the files so git can store all the files either on the local repository or on the remote Repository the next question is what is a bear repository in git so a bear repository in git contains information about the Version Control and no working files and it doesn't contain the special dot get subdirectory instead it contains all the contents of the dot get subdirectory directly in the main directory itself whereas the working directory consists of two things the first one is a DOT get subdirectory with all git related revision history of your repository and the second one is a working tree or checked out copies of all your project files the next question is what is a commit message so a commit message is nothing but an information that you provide along with the command called commit so that you are aware of what exactly that change the developer or the programmer is doing while committing any operation or any change so as you can see here the Syntax for commit messages get commit the option and the message that you want to write so the next question is explain some basic git commands so as you can see here on this slide these are the various commands some basic git commands that you should be aware of so the first command is the get init command as we have already seen what is a repository in git so this command is used to create a new local repository the next command is the get status command so this command lists the files that you have changed and those you need to add or comment the next command is git clone so this command creates a working copy of a local repository and the syntax is get clone and the URL the next command is the get add command so this command adds one or more files to the staging area of git so what exactly is staging area we will see in the subsequent part of this session the next command is get commit command as we have seen previously what commit message is that time we discussed just one thing about the commit command so this command commits any files you have added with Git add and also commits any files you have changed since then and the same tax is pretty much simple get commit and the option the next command is git push origin master so this command sends changes to the master branch of your remote Repository so these are the some basic commands that you can explain so the next question is how do you fix a broken command so in order to fix any broken commit you can use the command git commit hyphen hyphen amend so when you run this command you can fix the broken commit message in the editor so the next question is what is a conflict in git so git can handle on its own most merges by using its automatic merging features there arises a conflict when two separate branches have made edits to the same line in a file or when a file has been deleted in one branch but it has been edited in the other branch so conflicts are most likely to happen when working in a team environment the next question is how do you resolve a conflict in git so you can refer the diagram for more information about this question so there are a few steps that you need to follow to resolve a conflict and get the first step is identify the files that have caused the conflict in the Second Step you make the necessary changes in the files so that the conflict does not arise again in the third step you add these files by using the command get add and finally to commit the changed file use the command get commit so these were the four steps that you need to follow to resolve a conflict and get the next question is how do you revert a commit that has already been pushed and made public so there can be two approaches to tackle this question and you must include both the approaches in your answer because any one of them can be used depending upon the situation so the first approach is remove or fix the bad file in a new commit and then push it to the remote repository this is the most obvious way to fix an error once you have made the necessary changes to the file then convert it to the remote repository using the command get commit hyphen M and the commit message in the second approach you can create a new comment that undoes all the changes that were made in the pad commit to do this you need to use one command called get Reverb so we will talk about get reward in the subsequent part of this session Syntax for get revert is very simple so get revert and the name of the comment or the comment ID the next question is what is sub git so sub git is a tool for SVN to get migration it can create a writable get mirror of a local or a remote sub version repository and use both subversion and get as long as you like now you can also include some of the advantages like you can do a fast one time import from subversion to get or use sub git with atlassian bitbucket server we can use sub git to create a bi-directional git SVN mirror of an existing subversion Repository you can push to get or commit to subversion as per your convenience synchronization will be done by subgit so the next question is what is the difference between get pull and get fetch git pull command pulls new changes or commits from a particular Branch from your central repository and updates your target branch in your local repository whereas get fetch is used for the same purpose but it works in a slightly different way when you perform a git fetch it pulls all new comments from the desired branch and stores it in a new branch in your local repository if you want to reflect these changes in your target Branch git fetch must be followed with a git merge so in this case your target Branch will only be updated after merging the target branched and the fetched Branch so just to make it very simple for you there's one equation that you must remember so git pull equal to get fetch plus get merge so what is the staging area or the index in git before completing the commits any change can be formatted and reviewed in an intermediate area known as the staging area or the index so you can refer the diagram on your slide for more reference so this will give you a clear cut idea of what exactly is the staging area the next question is what is the use of get insta web git insta web is used to automatically direct a web browser and run a web server with an interface into your local repository so now we will have a look at the intermediate level of interview questions so the next question is what is get estring so git history represents a tree object including the mode and the name of the each item and the sha1 value of the block of the tree the next question is what is git stash so in this question you should first explain the need for get stash so often when you have been working on part of your project things are in a messy State and you want to switch branches for some time to do something else so the problem here is you don't want to do a comment of half done work just so that you can get back to this point later so to solve this issue there is one provision called get stash so stashing takes your working directory that is your modified track files and Stage changes and saves it on a stack of Unfinished changes that you can reapply at any time the next question is what is the function of get stash apply so as we have seen previously if you want to continue working where you had left your work then get stash apply command is used to bring back this saved changes onto your current working directory the next question is what work is restored when the deleted branch is recovered so the files which were stashed and saved in the stash index list will be recovered back any untracked files will be lost also it is a good idea to always stage and commit your work or slash them so if you want to fetch the log references of a particular Branch or a tag then run the command get reflog and the reference name so we will see about get reflog in the subsequent part of this session okay so the next question is explain the difference between get status and git diff so git diff depicts the changes between the commits commit and the working tree Etc whereas get status shows you the difference between the working directory and the index git status is helpful in understanding get a bit more comprehensively git diff is similar to git status the only difference is that it shows the differences between the various commits and also between the working directory and the index the next question is mention the differences between the get clone and git remote so git remote creates an entry into your git config that specifies a name for a particular URL whereas get clone creates a new git repository by copying an existing one located at the URL the next question is what is git stash drop so git stash drop command is used to remove the stashed item it will remove the last added stash item by default and it can also remove a specific item if you include it as an argument the next question is how do you find a list of file that has changed in a particular comment so to get a list of files that has changed in a particular comment use the command as you can see here on this slide get div tree hyphen R and the hash so given the commit hash this will list all the files that were changed or added in that commit The Hyphen R flag makes the command list individual files rather than collapsing them into the root directory names only you can also include the below mention Point although it is totally optional but this will help you impress the interviewer so the output will also include some extra information which can be easily suppressed by including two flags so as you can see here on the screen this command here you have included two flags the no comment ID and the name only so here the no comment ID will suppress the commit hashes from appearing in the output and the name only flag will only print the name of the files instead of their paths the next question is what is the function of get config so git uses your username to associate comments with an identity the git config command can be used to change your get configuration including your username so suppose you want to give a username and an email ID to associate a commit with an identity so that you can know who has made a particular comment so for that there are two commands as you can see on the slide get config hyphen hyphen Global user.name and your name that you want to give to the user and then the email so the command for that is get conflict Global user.email and your email address so the next question is what does the comment object contain so commit object basically contains three components first a set of files representing the state of a project at any given point of time the second one is the reference to the parent commit objects and the third one is an sha1 name which is a 40 character string that uniquely identifies the commit object the next question is describe the branching strategies that you have used so this question is asked to test your branching experience with Git so here we are going to discuss the three branches starting with the first one that is a feature branching so a feature Branch model keeps all of the changes for a particular feature inside of a branch when the feature is fully tested and validated by automated tests the branch is then merged into the master the second is the task branching in this model each task is implemented on its own Branch with the task key included in the branch name it is easy to see which code implements which task by just looking at the task key in the branch name and the third branching is the release branching once the develop branch has acquired enough features for a release you can clone that Branch to form a release branch creating this Branch starts the next release cycle so no new features can be added after this point only bug fixes documentation generation and other release oriented tasks should go in this Branch once it is ready to ship the release gets merged into the master and tagged with a version number in addition it should be merged back into the develop branch which may have progressed since the release was initiated so this was about the branching strategies okay so the next question is explain the advantages of forking workflow there is a fundamental difference between the forking workflow and the other popular get workflows rather than using a single server site to act as a central code base it gives every developer their own server side Repository the forking workflow is commonly seen in public open source projects a crucial advantage of forking workflow is that contributions can be generated even without needing everybody to push to a single Central repository that leads to the clean project history developers can push to their own server-side repositories but only the project maintenance can push to the official repository if developers are ready to publish a local commit then they push the commit to their own public repository and not the official one so after this they go for a pull request with the main repository that lets the project maintainer know an update is ready to be integrated so these were a few advantages of forking workflow so the next question is how will you know and get if a branch has already been merged into the master so the answer to this is pretty direct so there are two commands to check this the first command is the get Branch hyphen hyphen most so this command lists the branches that have been merged into the current branch and the second one is the git Branch hyphen iPhone no hyphen merged so this command lists the branches that have not been merged the next question is why is it desirable to create an additional comment rather than amending an existing commit so there are two reasons for this question so the first one the amend operation destroys the state that was previously saved in a comment if there is just the commit message that is being changed then that is not a problem but if the contents are being amended then the chances of eliminating something important remains more the second reason is that abusing get hyphen hyphen amend command can result in the growth of a small commit and acquire unrelated changes the next question is what does hook comprise of and get this directory consists of shell scripts that are activated if you run the corresponding get commands for example git will try to execute the post commit script after you have run a comment the next question is in git how would you return a commit that has just been pushed and made open so one or more comments can be reverted through the use of get reward this command in a true sense creates a new commit with patches that cancel out the changes introduced in the specific comments if in case the commit that needs to be reverted has already been published or changing the repository history is not an option then in such cases gitreward command can be used to revert the commits so alternatively there is always an option to check out the state of a particular comment from the past and committed a new the next question is how to remove a file from get without removing it from your file system so one has to be very careful during a get add else you may end up adding the files that you didn't want want to commit however git RM command will remove it from both your staging area as well as your file system but this may not be what you want so instead you can use the command as you can see here get reset file or the Eco file name and Dot get ignore so this means that git reset is exactly opposite to the get add command so the next question is could you explain the get workflow so to record the history of the project get workflow employs two parallel long running branches the first one is the master branch and the second one is the develop Branch so the master branch is always ready to be released on live with everything fully tested and approved that is production ready State the hotfix branch in master is used to quickly patch the production release these branches are a lot like the release branches and the feature branches except that they are based on Master instead of the develop and the second branch is the develop Branch this is the branch to which all the feature branches are merged and where all the tests are performed only when everything's been thoroughly checked and fixed it can be merged into the master here there's one more branch called feature Branch so each new feature should reside in its own branch which can be pushed to develop Branch as their parent one so the next question is explain the difference between the head working tree and index so guys you can refer the diagram that is on your slide for Clear understanding the working tree or the working directory or the workspace is the directory of source files that you're able to see and edit so the index or the staging area is a single large binary file which lists all the files in the current Branch their sha1 check sums timestamps and the file name it is not another directory which contains a copy of files within it whereas head is used to refer to the last comment in the currently checked out branch so the next question is what is the difference between folk branch and clone a folk is a copy of a repository normally you Fork a repository so that you're able to freely experiment with changes without affecting the original project most commonly folks are either used to propose changes to someone else's project or to use someone else's project as a starting point of your own idea get cloning means pointing to an existing repository and make a copy of that repository in a new directory at some other location the original repository can be located on the local file system or on the remote machine accessible supported protocols the git clone command is used to create a copy of an existing git repository in very simple word git branches are individual projects within a get Repository different branches within a git repository can have completely different files and folders or it could have everything the same except for some lines of code in a particular file the next question is what are the different ways by which you can refer to a commit so in git each commit has a unique hash these hashes are used to identify the corresponding comments in various scenarios for example while trying to check out a particular state of a code using the git checkout hash command along with this git maintains a number of alliances to certain comments known as the refs also every tag that is created in this repository effectively becomes a ref and that is exactly why you can use tags instead of committing hashes in various get commands so git also maintains a number of special analysis that are changed based on the state of the repository so in git commits are allowed to be referred to as relative to one another in case of most comments where the commit has two parents the raised to sign can be used to select one of the two parents however these can also be used to refer to comments that reside on remote branches allowing one to control and manipulate them from the local gate environment the next question is what is the difference between rebasing and merging so in git the rebase command is used to integrate changes from one branch into another it is an alternative to the merge command the difference between rebasing and merging is that rebase rewrites the commit history in order to produce a straight linear succession of commits merging is gets way of putting a forked history back together again the get most command helps you take the independent lines of development created by get Brands and integrate them into a single Branch the next question is mention the difference between revert and reset so reset is used to return the entire working tree to the last committed state this will scrub comments in a private Branch or throw away uncommitted changes reset changes which commit a branch head is currently pointing at it Alters the existing comment history so this command can also be used to unstage a file whereas get reward command creates a new comment that undergoes the changes from a previous commit so this command adds new history to the project it doesn't modify the existing history now we will talk about the advanced level of interview questions so the question here is how to squash last n comments into a single comment so there are two options to squash last and commits into a single commit and you should mention both of these options while answering such questions so in the first option if you want to write the new comment message from scratch you should use the following command as you can see here on the screen git reset soft head and git commit and in the second option if you want to start editing the new comment message with a concatenation of the existing commit messages then you need to extract those messages and pass them to get commit and for this purpose you will use the command get reset soft head and this command get commit edit hyphen M and the entire log command git log format reverse and the name of the head the next question is what is get bisect how can you use it to determine the source of a bug so git biset is used to find the commit that introduced a bug by using a binary search so the command for git bicep is pretty simple as you you can see on this slide get bisect sub command and the options this command uses a binary search algorithm to find out which commit in your Project's history introduced up bug you can use it by first telling it a bad comment that is known to contain a bug and a good comment that is known to be before the bug was introduced then get bisect picks the commit between these two endpoints and asks you whether the selected comment is good or bad so it continues narrowing down the range until it finds the exact commit that introduced the change so the next question is how do you integrate git with Jenkins so as you can see on this slide these are the four steps that you can follow to integrate git with Jenkins and I am also going to show you the screenshots for these four steps so first anyone who is aware of Jenkins or has used Jenkins you must be aware of this home page or the Jenkins dashboard so here you need to click on manage Jenkins and once you click on manage Jenkins you'll find this option here the manage plugins option click on that and then and you will have to search for the plugin here as you can see in this screenshot click on this plugged in and here you have these two options installed without restart download now and install after restart so you can choose any one of them and once you are done with that here you will be able to see this plugin that we have just downloaded along with its version number so these are the steps that you must follow to integrate get with Jenkins so the next question is how do you configure a repository to run code sanity checking tools right before making comments so here you must first mention what exactly is sanity checking a sanity or smoke test determines whether it is possible and reasonable to continue testing and now you must explain how do you achieve this so this can be done with a simple script related to the pre-commit hook of the repository the pre-commit hook is triggered right before a commit is made even before you are required to enter a commit message so in this script one can run other tools such as lenders and perform sanity checks on the changes being committed into the Repository so as you can see here this is the script that I'm talking about the purpose of the script is that it checks to see if any dot go file that is about to be committed needs to be passed through the standard go source code formatting tool by exiting with a non-zero status the script effectively prevents the comment from being applied to the repository the next question is what is get cherry pick the command git cherry pick is normally used to introduce a particular comments from one branch within a repository onto a different branch another common use of this command is to forward or backboard commits from a maintenance Branch to a development Branch this is in contrast with the other ways such as merge and rebase which normally apply many comments onto the another Branch so the Syntax for this command is very simple you just need to type git space Cherry hyphen pick space the commit hash the next question is what is get reflog the reflog command keeps a track of every single change made in the ref references that is the branches of the tax of a repository and keeps a log history of the branches and the tax that were either created locally or checked out reference logs such as the commit snapshot of when the branch was created or cloned checked out renamed or any comments made on the branch are maintained by get and listed by the reflog command so this command must be executed in the repository that has the Lost branch so if you consider the remote repository situation then you have to execute the reflock command on the developers machine who had the branch so the next question is how to recover a deleted Branch using the get reflock command so here as you can see on the screen these are the three steps that you must follow to recover a deleted branch and I'm also going to show you the screenshots okay so in the first step you get the history logs of all the references for that you just need to type get reflog and once you type this command you can see the history log in the Second Step you need to identify the timestamp of the branch that you want to recover so here in this case this is the timestamp that we are looking for the pre plot Branch here in the third step you just need to use the command git checkout hyphen B and the branch name this is a pointer reference when the pre-prod branch was created so if you follow these three steps you will be able to recover the deleted Branch so the last question of this session that is mention some of the git reflux sub commands so as you can see on the screen these are the commands that we will talk about four to five commands the first command is git reflog help so this command is used to open up the manual page the second command is the get reflock show so this command shows the logs of the references provided in the command line the third command is the git reflock expire so this command is used to prune the older reflog entries the fourth command is the git reflock delete so as the name suggests this command deletes single entries from the reflog history and the fifth command is get reflock exists so this command checks whether a reference that is a branch or attack has a reflux log history entries so these were a few commands like get reflock sub commands that you can answer in this question so with this we have come to the end of this session I hope you have enjoyed this session if you have any queries related to this session you can post them in the comment box below and we will try to get back to you as early as possible till then Happy learning thank you I hope you have enjoyed listening to this video please be kind enough to like it and you can comment any of your doubts and queries and we will reply them at the earliest do look out for more videos in our playlist And subscribe to edureka channel to learn more happy learning

Channel: edureka!

Views: 38,486

Keywords: yt:cc=on, git full course, complete git tutorial, git tutorial for beginners, git tutorial, git, github full course, what is git, complete git training, git fundamentals full course, git and github, git and github tutorial for beginners, git and github full tutorial, github tutorial, git and github tutorial, github tutorial for beginners, github, devops tutorial, devops git, install git, introduction to git, devops edureka, Edureka, git edureka, Git for beginners

Id: akD-DpolilE

Length: 363min 43sec (21823 seconds)

Published: Mon Jan 09 2023