 Hello and welcome to this video series on Git Prakken. Git Prakken is a GUI tool for using Git. And I'm using this tool and I'm really happy with this. So I would like to share this with you all. My name is Muhammad and I will walk you through how we can use it. In this introductory video, we will talk about the topics we're going to cover in this video series and what are our target audience. So the topics we're going to cover and before going towards the topics we're going to cover, we have some prerequisites. I am assuming that you have some basic knowledge of it. And you also know how we can use some basic Git commands like Git config, Git add, Git commit, Git status, Git branch, Git checkout, merge and put. Because I'm not going to cover these things in detail, rather I will use the Git Prakken tool and Git Prakken tool will use these commands in fact. So it is necessary that you must know about Git. Some basic information is necessary to use this video series. So what are we going to do? We're going to initialize the repository. We're going to commit some files. We will amend some commits, squash commit. We will create and merge branches locally and then we will push to the remote repository. Now what are our target audience? Students are the main target audience and they can learn a lot from this. Junior developers who are still in junior position and they can understand the working of Git with this tool. DevOps professionals can also use this video series and they can also learn a lot about this and this will be a helpful tool for them as well. For senior developers, mostly senior developers use the integrated Git with the IDE. For example, if they are using IntelliJ, Netbeans or Eclipse. So in all these IDEs, they have the plugins for using Git and senior developers mostly use the Git plugin. But this GUI tool is more interactive. It's more easy to use and more expressive than the IDE. Business analyst is also very, very helpful for the business analyst and technical project manager. So that's it and I will see you in the next video. Hello and welcome to the video series on Git Kraken. Today we will discuss about the GUI tool and we will create and initialize a repository. I have already downloaded the Git Kraken, but for your information, you can go to the git kraken.com and you can download this free GUI tool. So we're going to use this and I have already downloaded this tool. So let's open it. I have the Git Kraken here. So now we have this GUI tool and what we're going to do is first, we will create a repository on our machine, on my local machine, and then we will use this to commit some files and to use some Git command. So now we will create a local repository and then we will work on that repository. So I'll click on start local repo. I click on the start local repo and I can choose the location where I want to initialize. So here I can say, I can create a new folder, say Kraken 1, and I want to use this folder as a Git folder. So I'll select this, Kraken 1 and I'll say Kraken 1 demo. And with this we can create a repository locally and I'll say create repo. So I have a view something like this and this is my master branch. I have a default master branch and now I can create files. I can commit files. We need to keep one point in mind that we should have Git installed on our machine, right? If you don't have the Git installed, so it won't work because this tool is actually a Git tool. Okay, so let's create a file. We can create some files from here. So here in this section we can see all the files that we are working on. So I'll keep this simple because I just want to make everything simple so that you could understand it better. I'm not using any framework, any Java framework, any string or JS framework. We can work on that later. So let me create a simple file. So let's create a file and I can give the name of file here, File 1. Now this is my File 1 and this file has created. And now this is an editable mode so I can write anything here since it's, I think it's a text file. So I can write my first commit. Okay, so I can write my first commit. This is just simple sentence. So this file is in unstage file, right? This file is here in unstage category. So I can move it to the stage file using this button. Either I can click here or I can click stage all changes. So let me click on stage all changes. I can say save and save. Now it's in the stage file. And if I want to move it back to unstage, so I can just need to click here. If I click here, as you can see, it has moved back to the unstage area. So since we want to commit this, so let's move it back to the stage area. And now to commit, I can write a commit message here. Say first, first commit. Okay. And I can commit this file. Right. Now, as you can see, this was the initialized commit. This was a default commit that we get when we run the get get crackin. And this was our first commit. And in this commit, we have this file. So if I want to create another file, a five two, right? And let's say, right? This is five two. And then we will have to stage this file. I hope you know what it's unstage files, stage files. So, you know, all these different terminologies of it. So let's stage this file and save the changes. And then let's say, now we have an option of commanding the commit. The commit that we did in the first part, the first commit, if we want to amend that commit, we can click on the amend and it will take the latest commit, the last commit. And we can use that also, or we can create a new commit. So let's use that commit and we'll say commit with two files. And I will amend the previous. Now, as you can see, with this commit, we have two files here, file one and file two. But with the initial commit, we only have one file which is readme.md, right? So this was just a very simple example of how we can initialize a repo, how we can create files and we can commit files. In the next video, we will further talk about different features, right? We can create some branches and then we can move between those branches. Thank you. Hello and welcome to the Get Crackin' series. Now, we're going to create some branches and we will see how we can work with the branches here. So we are standing at local. So this is our machine and we are, we only have one branch which is master branch. And we have only two commits on the master branch. So we will create a branch from here. We can right click here or also we can right click here also. We can say create branch. So I will be creating a branch from here and I will select this option, create a branch and I can give the name. So I will say feature branch one. So this is my feature branch one. And as you can see that, so now I have, this branch has been checked out, right? I am assuming that you know what is the meaning of checked out, checked out means that when you, when you move your pointer to a branch, if I want to come back to the master branch, I'll say check out master, right? And as you can see, this tick mark is on the master branch. And now here is, as you can see, both the branches, the master branch and the feature branch are at the same level because we have just created a branch using the master branch. So let me go back to the feature branch one and I am checking out the feature branch one. And here we also have two files because we checked out, we created the branch from the master branch. So let me add something to this file. So we can, I can see changes made at feature branch level, right? When I'm at the feature branch. So I can save this, right? Now as I've saved this one, so I have to give the commit message or I can view this file is now in unstage category. So I can move it to the stage file and now I can give message. So I can say first commit or I can say feature implemented. And I can say the version of the feature is, let's say, version one and I can commit, right? So now this is feature implemented, which is on the version one. And also if I want to add something, so I can view all the files and let me add one more file here. So I can say feature file, feature file one and I will say feature file one. I am, so now this file is in unstage area. I can move it. I can save this and add it to the stage area. Now it's in the stage area and I'll say feature, say feature branch or feature implemented version one. Okay. So I haven't staged this file. Sorry. So I have to stage this file first. Now it's in the stage file. Now this file is in the stage section and now I can commit this file. So now at feature one level, I have, so in this commit, I have file two and at this commit, I have feature one. And here I can see, I can switch from the master. I have switched back to the master and I've checked out master here since you can see the tick mark is there. So it's also giving us a tool tip with information that's checked out. And if I want to check this out, I can say check out feature branch. And I'm now here. We can also create multiple branches. So let me create another branch at the master level. So normally in the cases, what happens is if you are working in a professional level or if you are working with multiple developers, there will be different people checking out master branch and they will merge their code back to the master branch. So you will check out from the master branch and then you work on your feature, you work on your bug fix or whatever you're working on and then you merge it back or you re-base on master before merging it. So let's try to create that scenario here and let's create one more feature branch So let's create branch here and I will say feature branch 2. So now the feature branch and the master branch both are at the same level and feature branch also contains these two files and let me create, for example, let us create and this is a commit hash, right? For every commit, we have a commit hash. Okay, so let us create file here. Let's say file feature 2 and file on feature branch 2. This is a file for the feature branch 2. Then we have to stage this file. We have to save and stage and now we can commit this and we can say feature implemented on feature branch 2. Okay, and let's say this was version 2. So as you can see, there are... this is a branch off. So this view, as you can see, it shows us that there is a feature branch which is this one which has two commits feature branch 1 has two commits and feature branch 2 only has one commit. So let's try to amend this file. Okay, so I will say some modifications in the feature and then I will save this file, right? Save this file and now since I saved this file, I have to... I have to stage this. Let's stage this and I'm not doing any amend, right? I can also amend but now I want to show the two different commits. So modifications implemented version 2 implemented on feature branch okay, and version 2. So let's commit this file. Now as you can see, we have feature branch we have two feature branches. We check and both feature branches we have checked out from master, right? So this is the feature branch 2 and this is the feature branch 1 and to make it further to make it more clearer let's create another branch sending at the master branch okay, we checked out it's not necessary to check it out but we can do that also let's create a branch here and let's say feature branch 3 now we have feature branch 3 and for example let's make change here feature branch 3 added this line, right? So this line has been added by a feature branch the other person who is working on the feature branch 3 and with this we can save this file and stage this file, we have to save this as we saved it we can go here and we can stage this file, right? stage this file and we can say feature added feature added and let's say we can say version 3 the version is right now depicting like a branch as you can see here we have three branch so this one is the feature branch 1 then we have the feature branch 2 and then we have the feature branch 3 and all these three we branched it out or we created these branches based on the master branch since we created based on the master branch so they have all the code which are which is there on the master branch and we picked up that code and then we started working on that code so when we check out from any branch we take all the changes of that branch all the files of that branch and then we work on that so this is how we can create branches in gitprakken and we can then see different branches here that's it for this lecture and I will see you in the next lecture hello and welcome to gitprakken today we are going to talk about merging so we will merge branches to the master so for example we have three branches feature branch 1, feature branch 2 and feature branch 3 and we are going to merge one of these branches to the masters and we will see how it works before moving and implementing the merging feature I would like to briefly talk about the merging feature and I want to clear some concepts for those who are still confused how merging works for example we have a master branch we have a master branch and we have a feature branch for example feature branch 1 and we have some commits so let me change the color and let me choose okay so we have summit 1, summit 2, summit 3 and now we will branch off from here and we will create a feature branch so we will create let's create a feature branch from here this is a feature branch and then we have some commits here right and now we have three commits and we want to merge it back to the master when we merge to the master we have a new commit at the master that will be called the merge commit so we will have a new commit at the master that will be called a merge commit this will be a merge commit and we will merge this into the master so all the code all this code is merged into the master and this call and this commit will be called merge summit so this is our merge commit one thing which we need to take care that is the merge conflict when we merge the code from one branch to another branch we can have something called merge conflict now what is a merge conflict a merge conflict is that you are we are merging to files file 1 and file 2 both are same files right this is file 1 and this is also file 1 and both the files have the same change on the same line for example at this line there is a change and this line this is also change change means there is some code written or something is there and for example this is this file is on master branch and this file is feature branch now the get doesn't know how to merge this which code or which line to take or what decision it should take so it then says ok there is a merge conflict you have something here and something here and I don't know how to resolve it so we can we will have to resolve it so this is how it works in practical cases in in professional software development where you have multiple developers then there is a little bit difference here and that difference is the difference is we have multiple developers for example you can have feature branch 2 feature branch 3 you can have feature you can have multiple developers and they will also be merging back to the master right they are multiple developers are working on multiple features or different features in reality you will have this tree keeps on growing right it's not constant it's not standing at the point where you branched off right it is keep on growing so the strategy the good strategy is first pull before merge the standard that we use is pull from master right pull from master and then merge to master and then if you have any merge conflict so you can resolve merge conflict and so then you can and when you merge back to the master merge back to the master you definitely you have merge coming here right and this is how this all works so that's it for this lecture and in the next lecture we will implement the branch merging right hello and welcome to the video series on gate today we are going to talk about merging in the last video we saw how we can merge and what is the concept behind merging when we merge one branch into another branch so now let's see how we can merge different branches so we have four branches in total master branch feature branch one branch two and feature branch three so and let's see how many files we have in all these branches so if I if I select the master branch at master branch we have to commit right you can see here we have to commit at the master branch master branch is here and all the commits below this icon are related to the master branch we have to commit in the initial commit only have readme.amd file and in the second commit we have two files file one and file two and now now let's see how many commits we have for the feature branch for the feature branch as you can see this feature branch is we created this feature branch from the master branch so here is the link of the feature branch and we have three commits one two and three so let's click on the first commit we have one file which is file two and as you can see this is a modified file so file two also file two is also there in the master branch so let's click on this one let's let's see this this commit is related to the master branch and we have file one and file two so this plus sign shows that we added new files to this branch right and then we modified file two when we created this feature branch we modified file two and that's why we have this special then for the second commit on feature branch one we added a new file called feature file one right and then we added and we modified another file which is file two so the file one and the file two were initially there at the master branch when we created the feature branch we got all the files that were there in the master branch we modified file one and file two and then we added a new feature file so let's try to change something in the feature branch I have already checked out feature branch and so this is the file two and let me add some comment here new some modification I added one line which is some modification just add two words and let's add something now we can create a new commit or we can amend the last commit right so what I want to do is I want to create a new commit to show you a new commit I will save this file save this file and now we have one file it saves one file change in working directory so let's view the change okay so this file we just change let's stage this file and say changes implemented okay and let's commit this change so now we have four commits on the feature branch right we have this commit which is the updation of file two then we added a new file with the name of feature file one then we have we added something we added some text in the file two and then in the last commit we again added something we change we implemented some change okay so now let's merge let's merge feature branch one into the master branch right so to merge this I will I can right click on this master icon master branch icon and I can select this option merge feature branch one into master or I can right click here and I can say merge feature branch one into a master so let me use this option I can click here and I can say merge feature branch one into the master and now the merge has been done as you can see we have a merge commit which is merge branch feature branch one so we merge the feature branch one into the master branch so now if I click on this master branch and I checked out this master branch and I have clicked all files so I can see all the files feature file one which actually which actually is a file we created at the feature branch one then we have file one then we have file two and then we have read the file we have all the files here at the master level so we merge feature branch into the master branch so I hope this will be helpful for you then you must have understood the concept of merging and as you can see the link this link also shows these lines shows you that where we are branching off or where we are merging into so if you look at these lines of the get cracking tool so you can easily understand that's it I will see you in next lecture thank you hello and welcome in this video we are going to talk about merge conflict and how we can resolve those merge conflicts so when we merge a branch into another branch we often come across the situation in which we have modifications on the same line and then get cannot identify which line to take and it shows that we have a conflict we have two different codes at the same line and it needs the developers help to decide which one to ignore or which one to add so let us create that merge conflict case here and then we will resolve it so in the last video we merge feature branch one into the master branch and now we will and we want to merge feature branch two into the master branch so in the master branch if I click all files then it will show the all files of the branch don't click on this box it will only show me the files which are related to the commit with this commit right so let me click on this and now I have 1, 2, 3, 4 files so file 2 is here and if I go to the feature branch 2 so we have file 2 here let me change something in the file 2 so that we could produce the merge conflict case okay so in this file we have one comment so let me write a new line here file modified at line 1 I have this let me save this save this file and I have now a chain so I will stage this file and I say file 2 modified feature branch 2 okay now let's look at the master branch and on the master branch of file 2 we have a different line at line 1 we have a different sentence so it looks like that it will create a merge conflict which cannot understand which line to take now let's merge into the master branch so I have checked out feature branch and if I right click on the master branch it says merge master into feature branch which we do not want so I will have to check out master branch and then we want feature to be merged into the master so let me check out master branch now I have checked out the master branch and now if I will click on feature branch 2 now I have an option that merge feature branch 2 into the master so you will have to check out the branch that you are merging into and then you will merge the branch that you want to merge so I have checked out master right we have checked out the master and then we want any branch we want to merge into the master we can just right click and we will get this option so let's click this option and let's check out what happens right so it says merge failed there are merge conflict that needs to be resolved now what is the merge conflict how we can see the merge conflict we can click here and here you can see so at line 1 it says file modified and which is on the feature branch 2 and on the master branch there is a different code line so it doesn't know what to do so what we can do is this is the output what we really want to do so we say okay add this line now file modified and we can say okay add this line also and add this line also and add this line so we took all the options we merge this and we have resolved the conflict now we can save this now we have saved this file and we have staged this file has also been staged and now the messages merge branch all good now you can see there is no conflict resolution message and now let's submit and merge successful we have merged successful so that's it and thank you hello and welcome today we will talk about detached head state so we will understand what is a detached head state what can be the problem with the detached head state and how we can come back to the normal head state let's first understand what is detached head state so we have a branch let's suppose we have a feature branch branch and we are making commits and when we make the commit we have a head that points to the latest commit on the branch for example we will have a head pointer that will point to the latest commit on that branch if we make another commit for example now this head will move to the latest commit here and point to the latest and we won't be having the pointer pointer to the old commit so if we make another commit now the pointer will move forward and it will point to the latest commit and we won't be having the pointer here so the latest commit will be we can reference the latest commit the head points to the latest commit and it also gives the reference to the branch it also gives the reference to the branch that this commit is is related to this branch and if we make another commit then the same process we will have the head pointer pointing to the latest commit now what is detached for example if we check out a commit if we check out a commit let's say this commit if we check out this commit then the pointer the head pointer will not be pointing to the latest commit rather it will be pointing to the checked out commit so now the pointer will point towards the checked out commit and this state this state in which the pointer the head pointer is not pointing to the latest commit is called a detached at the state it's the head has been detached from this latest commit detached at state now we understand what is a detached head state when the head pointer is not pointing to the latest commit now this pointer is not actually giving us the information of the branch because the head has been detached and if we make any commit in this state for example now we have checked out this commit and let's say the share of this commit is 1 0 6 7 V random number I just show so if we make any commit here if we make any commit here or if we make any commit here so there is a possibility that these commits can be lost so what we can do to preserve these commits we should make a branch we should create a branch and we can preserve it so now with the help of git tracking I will show you how it works and then that will be easier for you to understand so now we know what is a detached head and now let's see using the git tracking how we can we can produce this case here okay so now let's try to produce that case let's try to first create a detached head state and then we will see what can be a detached head state so now we have different commits here so this is the first commit and either we can check out this commit or we can check out this commit this commit contains two files let's check out this one this is an easier commit and we only have one file so I will right click and I will check out this now as you can see my head pointer is pointing here and now let me commit something detached head state so I will go to the file I will say this is detached head state just one line and I will save this I will save now here I can see one file change in the working directory I will review the change as you can see here a message that you are in a detached head state why we are in a detached head state because this commit we check out this commit and this commit is right now not belonging to any branch yeah it is belonging to a branch but since we have checked out it doesn't belong to any branch so what we can do let's paste this file and let's and let's make a commit so we say detached head commit right and I can commit so now I am in a detached head state so this commit is a detached head commit right okay what is the problem what can be the problem now if I check out any branch for example if I check out master now you must notice that when I will check out this master I will lose this detached head commit right so let me check out this master branch and as you see I have checked out my master branch but I don't have the detached head submit anymore so this is a problem this this is something which we need to take care that if we are in a detached head state and if we are committing something and if we check out any other branch then we will lose all our work now what can be the solution of it let's produce the detached head state once again so now let's make the commit from the same commit say detached head state okay let me say when commit this file same again giving me the information that and it's also giving me the tool tip if you can see says that if you check out another branch or commit you might lose any commits created in detached head state and we just saw so now let's page this file and say detach and commit and let's commit this file now how I can preserve this information I must create a branch right I have an option that create create branch here so I will create a branch and I will say for example this was a hot page this was a production hot page so and I will create the branch with the name of hot page one now my detached head commit is a part of a branch and now it is safe now if I check out any other branch that's the definition of master now my detached head commit is still there because my detached head commit is not a hanging commit anywhere it's now it's linked to a branch and I can use this branch to merge or pre-base or whatever I want so this was about the detached head state and what can be the possible problems and how we can how we can solve the problem so that's it for this lecture and I will see you in next lecture thank you hello and welcome in this video we are going to talk about squashing commits so let's first understand what is a squash how we squash the commits and why we need this let's create a branch for example we have a feature branch and we have some commits here for example this commit so here we created a file for suppose we the message of this commit is file created and then we have another commit and then we say let's say we see method updated and then we made another commit and we made some mistake in the last commit and we said here that method fix and then we did another commit and then we say that error resolved now we have these all three commits for example here we see and these are actually the same file we are doing some updations and every for every commit we are updating something but we don't want we don't want these to be to be pushed to the master to be pushed to remote why because because these don't look good instead it would be better that if we would push only only one commit having all these changes it will be more professional and it will be more clean that if we push all these changes all these changes but in one commit so in this case we can use a squash what squash will do squash will combine these three commits in the parent commit so this is the parent commit right this one is the parent commit and it will combine all these three commits in this commit in this one and we can then we can then have only one right so after squash what will be the case for example we have future branch and after squash we will have one commit and then we can update the message whatever we want to say we can say that we can say new feature edit right we can say so it's a much proper and we can and we don't have any repetitive commits we only have one commit which looks good and clean and we can then push this to the remote represent right and if we are working in a team and then team looks at this one commit then it looks good and this one will look a kind of a garbage and it won't be a good impact in your team members so for this purpose we can use squash so now let's look at the good crackin and let's see how we can squash the commit okay so now we are here and we have the good crackin tool and let's say we have this master we are right now at master branch and we have one file here so this master file and we don't have anything in this master file let's say we add something we add some lines so we say content added let's say one dot content we added some content or some line of code or something like that and and we will save this and now we have one file in the working directory we can stage this file and we can say new content added and we can commit this file and now we want to make another change so we will open up the file and we will say for example two dot some content added right and let's submit this file as well so when working directory we stage this file and then we say new content added added and then we want to add another change or we want to update this file again then we might say something some new content added and we can save this file we can save this file and we can again do the same thing master stage the file and we can say new content added free now if you look at this these three comments these three comments don't look good because there are some small changes we are doing in the file and if we push this file to the master then it won't look good it's not giving a good impact so what we want to do is we just want to send one commit but we want to have all these changes also we don't want to lose our changes so what we can do is we can squash the commit so there are some conditions in squashing and let's see what are those conditions we have these five conditions when we squash using gitcrackin so we have more than one commit selected there should be more than one commit selected it's very obvious so that we could squash youngest commit is the head genealogically consecutive it means the parent-child relationship should be there chronologically consecutive oldest selected commit has a parent the last commit should have a parent so let's see and let's go back to the gitcrackin and let's see do we qualify all these five criteria now if we look at our changes so we have the youngest commit and the head is pointing towards the youngest commit the commits are chronologically consecutive and genealogically consecutive also and the oldest commit this is the oldest and it has a parent which is this one if I select all these commits I select all five sorry all four here we can see we have four commits and here we have the details of all four commits I will right click on any commit and I can say squash four commits when we will squash these four commits these four commits the first three commits will be added the last commit and that's how we can get rid of the additional or the repetitive commit so now let's click this option so now as you can see we have only one commit here and let's check the file so if I click on this master file I can see that my content is still there the data is still there but I have squash all the commits and now let's see the message this is the master file which is the actual message and we also have the messages from other commits so this is the new content added message which was the commit message of one of the commits then we have this second message and then three and we definitely we don't want this to be there because this is not needed at all so we can remove all these from the description and now we can also change this message and we can say new file added I think it's enough and we can update the message now we have the new message new file updated we don't have the repetitive commits or the unnecessary commits that we did and now it's good to go we can push this to the remote repository I hope this will be helpful for you and see you in next video thank you