Git and GitHub Masterclass - FastTrack your Journey to Git!

1. Quick Intro on the Course!: Welcome to this course on Git and GitHub. Here are some of the reasons why you should learn Git and GitHub. More than $83 million per cent across the globe use Get up. 90% of Fortune funded companies use GitHub. More than 200 plus million repositories are projects are currently residing on GitHub. Github is a key component of your DevOps journey. In fact, if you want to pursue DevOps Catia, GitHub is a starting point. You're not getting anywhere unless you learn GitHub. Github is also the most popular code hosting platform compared to its competitors, like Bitbucket or GitLab, get is the most popular version control system to ever exist. It's almost a must-have skill for any IT professional. And I guess you already know that. Here are the goals of this course. I'll teach you everything you need to know about Git and GitHub. I've been using it since 2014 and I've even had experienced in managing teams and meeting the project deadlines. I have fine-tune the syllabus accordingly. And you don't have to refer to any other books or other courses. You will learn everything you need in this course alone and you don't need to go. Anything beyond this. Make you feel confident to handle any project tasks related to Git and GitHub. Teach you how to contribute to open-source projects and make you confident with interviews. But why should you learn from this course? Aldi, important and essential topics are covered in the first few chapters. And all the topics that are not essential or discuss later in the course. Just we're watching for six to ten chapters. You'll start to feel confident to start taking up the task later to get up. That being said, I highly recommend you to watch the entire course. To learn the entire subject. I combine multiple related topics in the same lecture to save your precious time. If it makes sense for me to combine multiple related topics and teach them together, I always do that. Not only to save your time, but also to teach more effectively. I'll teach you this object with real-world scenarios, use cases and workflows. I've handled some of the toughest project challenges myself. And I can certainly use that experience to talk about some of the real-world scenarios where you can apply all these concepts. I have unique ability to teach very complex concepts into easy to understand manner. You'll understand this by yourself once you make progress in this course. I also have expectations on who is watching this course. Forget about what you already know and start fresh. If you already know something about Git and GitHub or any related subject, I want you to just wipe out everything from your mind and start with a clean mind. Otherwise, you might hear some conflicting terminologies, which might then start to confuse you. Dedication and commitment to learn the inter-subject were living in the world of distractions. Unless you put efforts to stay committed and dedicated to learn the entire subject, you're not really learning anything. Practice what I teach. Practicing for once is equivalent to ten times of reading set by somebody somewhere. But it makes perfect sense. You should try to practice what I teach. Otherwise, you might lose track of the subject and get confused. Stay focused on one course, whether you take this course or some other course, complete it fully, and then switch to other source of information if you wish. But don't mix things together, which will again create a lot of confusion. Dedicate just one hour every day without distractions. It's better to learn for one hour with complete focus than learning for eight hours with not-so-good focus. Keep that in mind. Next we'll start to understand what is get Github, what is version control system, et cetera, with real-world examples? And that's a great way to start our course. I'll see you next. 2. 0101 Need For Version Control System and Git Part 1: Why do we need version control system? Meet Mr. Bob, who is an investment advisor. And due to all the amazing work he's doing, his client base has increased significantly over time. And so he sees a need to have his own personal website. So Bob had envisioned a website of its own. And Bob being a non-technical guy, he thought of taking help from a freelancer to get the job done. So he met sender who is a freelance or unexplained him everything what is expecting in his website and give the deadline as 24th of February, which happens to be his birthday to it's under a grade and started working on the project. Insights on those computer. There had created this folder called investment app, inside which he created all these files which will make that website. After a few days off work, cylinder had finally finished working on creating the website. He tested it. He also hosted it on a hosting provider or on a Cloud service provider. God, the application up and running and shown it to Bob. Bob was quite impressed with the work done by sunder. And so now he decided to add couple of more features into his website. And you get the deadline as 20th of February. Two goods sooner once again, had accepted the deal and started walking on those additional features. And once again, cinder had added all those features, hosted it on hosting provider, got the website up and running and shown it to Bob. But this time, however, bob was not completely satisfied with the work. Even though the latest features introduced after 24th of February, we're working fine. The features that were working earlier seem to have broken or are not working as expected. So Bob had explained the same two cinder and asked him to undo all the new changes and bring back the application to what it was on 24th of February. To it soon they're hesitantly accepted. But unfortunately for Cinder, It's not going to be an easy task to undo all those changes because there's a lot of new code introduced after 24th of February, and the code has scattered across multiple files. It's really hard for sender to recollect each and every line of code that was introduced and undo all those changes. However, since the one to accept the deal, to keep the client happy, after a lot of sleepless nights and after a lot of frustration and a lot of testing center finally got the job done. However, this time, in the midst of Bob's deadline, and Bob was wondering why it took so under couple of weeks just to undo the changes. Well, it only took him a few days to create the entire website. This has resulted in Bob being not satisfied and soon, soon started to see similar kinds of issues with some of his other clients as well. They were complaining that some of the features were not working as expected, which had worked earlier. And so they wanted to get them fixed or they want to go back to previous versions of their web applications which are working fine. So sunder gave it a thought and finally came up with a genius idea, which are somewhat solve this problem. We'll talk about it in just a while. 3. 0102 Need For Version Control System and Git Part 2: So what's in there had started to notice is that he didn't have backup Office client websites. If you had a backup of their websites, he will have opportunity to either go back to previous working version of their website or at least n lies the problem by comparing one version with the other. Cylinder came up with a brilliant idea to sort of solve this problem. What you started to do now is, for example, let's consider the investment app that we were talking about. Cinder creates a folder called investment app V1 and 14th March, which is the date on which this project was delivered to customer. And then assume that Bob had asked him to introduce couple of new features. This time cylinder is not going to make any changes in this portion of the project. Instead is going to make a copy of that project, name it as V2 and introduce all the new features. And similarly, if Bob were to ask some there to add even more features, he's going to make a copy of the latest version of his project, name it as V3 for instance. And then make all the necessary changes, so on and so forth. So every time he introduced a new feature or introduce a huge chunk of code, is just simply going to copy the folder or the project and make necessary changes. This time. Again, let's assume the same case where Bob was complaining that Washington before is not working as expected, and that he wished to go back to Washington V3, which was working fine so soon that doesn't have to take their foot off reverting all the changes. He could just remove the V4 folder from the server and replace it with V3 working version of be-bops website. Or if Bob had insisted him to fix the bug, that can actually compare the files between v3 and v4 using a comparing software like beyond compare, for instance, pinpoint exactly the changes that were newly introduced, analyze the problem, and fix the problem. While this has somewhat solve the problem, suddenly started to realize that this is taking up more memory than needed. Because sender is not only making a copy of all the files that he had modified, but also the files that he never touched. So this is going to take up a lot of space and it's becoming really hard for similar to manage. So suddenly came up with a much better idea, which is actually to create versions of the files inside the project. What do I mean by that? So assume that you once again have a project like this with all these files. Now of course in this case I named them as HTML, but this could be any file, this could be an image file, CSS file, JavaScript file, java file, whatever. For the sake of this example, assume that we have all these files. Now, assume that center is introducing a new feature which has something to do with file B and C. So instead of creating a copy of the entire folder that is going to make a copy of the latest version of these two files. This is going to make a copy of file B and file see, introduce all the code required for feature one. And if you want to introduce another feature, and this time assume that the changes needs to go and file the file, see some of that is going to simply make a copy of the latest versions of file a and file. See, for example, in this case it's going to make a copy of file here as well as a copy of file C, version one, which has the latest version of file C. And then he's going to introduce the new feature in it. Once I can assume that Bob had asked sunder to remove feature to altogether and that we wish to go back to earlier version of his walking website. Guess Watson, they can just get it off the V2 files and only keep the V1 files as simple as that. And if you want to fix the bug instead, he can just compare the version one file with Washington to File and pinpoint exactly what's going wrong by using a comparing software like Beyond Compare. However, Watson they started to notice is that even this is not feasible because it is becoming incredibly complex to manage multiple client projects. For example, sender needs to rename all these files back to their original names before deploying them to the remote server. And he's also started to notice that his files are ever-increasing, which is creating a problem not only in terms of organising the files, but also it is taking a lot of space. At this time since I've started to realize that it's time to let the software do the job for him. A software that will manage versions as software that will track historical changes, create backups, and allow reversal of changes, etc. This is the core reason why somebody somewhere had to come up with the software that will do this job. And that's the birth of get. Now, get does much more than just this. But I'm not talking about them right now because at this point in time, you don't know what is GitHub team collaboration branch in merging and stuff like that. I'm going to preserve them for upcoming lectures. And I'm pretty sure you must also be having questions like, what is GitHub or GitLab, what is branching, etc. Well, you just have to wait for that. I cannot fit everything under single video, how patients and watch the rest of the course. And you'll find answers to all the questions you might be having. But truth be told. I like how soon the maintenance is smiley expression all throughout. No matter how his life is turning around him. Something to learn from, isn't it? What did you just say? No. No. I'm just saying that you have a great sense of fashion. Okay. 4. 0103 VCS How it works: Let us see how the Version Control System, or simply visio software works at a very high level. Once again, assume that we have sunder, who is a freelance developer, and cylinder has got a new client, Linda, who is a restaurant owner, and she wanted to have a website for her restaurant. So to accept online orders from our customers. You can tell based on their smile that he's ready to take up the project. But based on his past bad experiences with some of his other clients who now have decided to use a VCS software to manage versioning. Cylinder in his local computer, creates a folder with the name restaurant app, spends a few days and introduce all the files required to create a minimum functioning website. The video software will have its own data store to store all the historical data and backups. When I say Datastore doesn't necessarily have to be a relational database or some form of database software. It can be as simple as filesystem. We sell software is typically tend to use your own file system to store the backups and historical data. As we progress through the course, you will understand this concept much better. But for now, just assume that this is some kind of a backup store to store the state of the project. Now assume that cylinder is quite happy with the progress he has made in his project. He has got a minimum functioning website and has tested everything. Everything is working great. So it has decided to save the state of this current project. So to retrieve it back when needed. So he's going to instruct the visio software to store the current state of the project, typically by running a command. Once it runs the command that we see software would essentially make a copy of all the files and store them inside the data store. Now assume that sender has got a new requirement to introduce feature one. And assume that all those code changes would need to go inside file, bn file, see some that has made all those changes. Once again, is going to run the command to save the state of his current work. But this time the vizier soft, we'll store the information slightly different compared to how it's stored earlier. This is how it's going to store. Since no changes were introduced in file a, the VCU software would only store the reference of defile a. What that means is it will just have information about the location where they file a copy is residing. And the reason for this is obvious. We don't want to unnecessarily make a copy of all the files that were untouched or unmodified and take up this space. When it comes to file B and C, though, we have introduced new changes. But the easiest software is not going to make a copy of these files. Adr. What is going to store is actually the difference between the modified file and the latest version of the same file. And it's going to store the same in the Datastore. We call each one of these has a bad set. Essentially, a bad set is the difference between the original file and the latest version of the same file. And the reason for that is once again obvious. We want to save this space as much as possible. Similarly, assume that we have new feature called feature to which is introduced. And file a and file B were modified. And this is how the VCS software would store the data. So we have PAD sets for file a and file B. And then for file C, we're only going to store the reference of its previous version. And similarly assume that we have another feature. We are going to make modifications to file B. And this is how the VCO software, which store the information, now assumed that cylinder is not happy with the version for raw file B and that he wanted to get back to version three of file B. So it's going to insert the same to the vizier software. The visa softer would then pick up the original copy of file B and then apply all the patches that came after it till version three to make up the version three file B and is going to give back to Sunday. He can do whatever he wants to do with it. Similar listener can also write the command instructing the software to get the entire project torsion three, for instance, and the software is going to do just that. Now, obviously there are a lot of vizier softwares available in the market. We have good Mercurial, SVN, et cetera. And they all differ slightly in terms of how the managed historical data. But in general, this is how the manage historical data. Now let's dive deep and understanding what exactly happens, what happened, why? I don't care how it works internally. It doesn't help me with my job anyway. I just want to know how to use the software. That makes sense. That makes sense. Just one last video and then we'll start installing the gate and get our hands dirty with lots of practice. How about that? Thanks. You're welcome. 5. 0104 DistributedVCS: Let's talk about distributed version control system. Linda is quite happy with the work done by Sunday and she started to notice increase in our business revenue ever since she launched a website. And due to increase in customer demands, she now has decided to have even more features in her website. She wants second approach is to do the job for her. But this time, due to increasing demands from our customers, she has a very short deadline to watch. Sender has accepted the deal, but somebody is quite aware of the fact that he cannot do this all alone and that he needed to hire a couple of folks in his team, help him deliver the project on time. So sunder hired a couple of folks meet Asia and Luke, who are the new members in the team. Sender has also provided them with a brand new MacBook Pro, shared them the project files or the code. Or maybe he has hosted return an FTP server, shared the link and ask them to download. And he has also instructed them to install the software on the local computer, given all its benefits. Of course, under has his own local enrollment and its own set of problems as they're making progress in the project. Since I started to notice few problems with using a local version control system. Some of the problems that they're facing are these no historical changes of other members. For example, if he shall wants to take a look at historical changes done on file a, she can only take a look at historical changes that she has done, but she doesn't have access to historical data of somebody else, for example, cylinder, because he only has access to her own data store, but not so in this data store. Now this is clearly a problem. Unless she gets access to the entire history of changes, she cannot effectively work on a task. Another problem is it's difficult to maintain the latest code base. Whenever somebody makes a change, they need to let other developers know they've done that change and the need to copy that code into their local machine as well. So to have latest version of the code in all the computers, this is of course practically impossible, especially when you have multiple team members working on a single code base. And things would become even more complicated if two people happen to work on the same exact file. Another problem is no centralized management of roles or access control. For example, assume that someone wants to put restriction on Luke that he can only access particular set of folders in the project, but not the other folders. Well, with local Washington control system, he doesn't have control on that. Sender has thought about all these issues that they're facing and has done a research on Google. And finally came up with so-called a centralized version control system. Would just simply means that this time, instead of having the data store, as well as the code in the local enrollments are on the local machines. It's going to be on a centralized server. And everybody would pick the code from the centralized server, work on it, and then send it back to the server so that others can use their code. And with this, we can get rid of all the problems we had with local version control system. Once again, if esa wants to take a look at all the historical data of particular file, she will easily get access to it. Because this time, all the paths sets are maintained in a centralized server and all the developers would have access to it. And with just a simple command, everybody would be able to get the brand new latest code and they can start working on top of it. So to avoid conflicts. And Cinder can also have better control as to who can access what. Since everything is hosted on a centralized server, he can now start to use role-based access control. And he will have control as to who can access which folders of the project, et cetera. However, centralized version control systems come with their own set of problems. For example, what if several goes for a toss? Or what if somebody hacks the server? What if he shows having connection issues? Maybe her Wi-Fi is not working. In all these cases, developers cannot work on the project. They might as well risk losing the entire code if they're unable to record the server. Considering all these drawbacks offers centralized version control system, had to find out an alternative. And that's how he came across with a distributed version control system. It's basically the best of both the worlds of local VCS as well as centralized VCS, eliminating all their drawbacks. This time with centralized version control system. Instead of having one single depository as the centralized server. Here, every single durable will have their own server and each one of the developer will have a copy of the entire history or versions of the code in their own local machine. What that means is even if the server what to go for a task, everybody have their own local copy of the entire code as well as the historical data. And if someone like Asia, what to lose connectivity, maybe because of a Wi-Fi connection, she can still make progress because she's having everything in her local computer. She can make changes. And whenever how connection comes back to normal, she can deliver the code to the centralized server so that other developers can get them and do something with it. Or in case of a data loss, every dollar plus having a backup of the entire code base. So they can recall from some of the examples of centralized version control systems or CVS subversion or simply SVN Perforce, or some of the examples of centralized version control systems. Some of the examples of distributed version control systems are Mercurial, Bazaar and Git. Git is a distributed version control system. All the developers would have to install Git on the local machine. In addition to that, we also have GitHub, which acts like a centralized server. I think we've gained enough knowledge to start working with Git. 6. 0105 InstallingGit: Okay, let us see how we can download, install, and configure, get on our local enrollment. Now assume that I'm a freelancer and I got a very small project which I feel I can walk alone. Forget about team collaboration, forget about multiple people involved in the project. Forget about GitHub for the time being. Let's just stay focused on get. So go to Google and search for download, get on the first link, but makes sure that it belongs to the website. Get hyphen SCM. That's the official website of get. Once you're there, depending on the operating system you're using, click on the relevant link. Now by the time you're viewing this page, you might see a different layout. But you got the point. You just have to click the link that is specific to your operating system. I'm using Windows. In my case, if you're using macOS, there are a separate set of instructions for the same. Just follow them. And while installing, you can leave everything to the defaults and proceed with the installation. And it's not necessary that you understand each and every step while installing. That's perfectly normal. In case if you have any problem installing in macOS sets, do get in touch with us and we'll be able to help you. But since I'm using Windows, I'm going to click this here. I basically got couple of options. The first of which is the installer version of Git, and the other is the portable version of Git. If I download portable version, I can start using Git without having to install it. And this might come in handy, especially if I want to work on multiple computers and I don't want to install Git on each and every computer. I can just dump all these files onto a pen drive or a thumb drive and then start using good on all those computers. But I'm going to go with installer. I'm using 64-bit OS, so I'm going to click on this. Well, for Linux and Mac users, you might already be having Git installed. You can just verify it by running a command. I'm going to show you that command in a while. Or you might already be having those libraries, so you just have to install them. You can defer to the installation instructions for the same. So I have this downloaded. Let's now start the installation process. If you have patients go through this entire license, I don't have so much of patients, I just clicked Next. Now, while installing Git, you might come across with certain steps, are certain prompts, are certain terminologies that doesn't sound familiar to you. It's perfectly alright. As a rule of thumb, just remember, keep everything to their defaults and proceed with the installation. It's not necessary that you understand each and every step in this installation process. Since I have worked on it for a long time. I understand what is being asked here. But for you, you don't have to understand everything. I would only walk you through the steps that I feel you'd be able to understand based on the level of knowledge you've gained so far in this course. So I could just leave everything to the defaults. But what this prompt is basically asking us is it is asking us to choose the components that we want to install. We're going to talk about Git Bash and get go. In the next lecture. You can just ignore and keep rest of this stuff to the defaults. We don't want to get into too much detail. It's not what that here it is basically asking you to choose a software to edit dot get files. I have installed Notepad Plus Plus in my computer, and I can choose that. And I would also recommend you to use the same software. It is open source. You don't have to pay anything for that. Download Notepad Plus, Plus, it's an amazing tool. Choose that and click Next. Leave this to default because you don't know what is a branch at this point in time. So it doesn't make sense for me to explain you about this step. So we're going to leave this to default. Okay, in this tab is basically asking us whether are we going to use Git Bash only or are we also going to use the command line of windows? This step is specific to Windows. You may not be seeing similar installation steps. Effort installing Git on other OS like Linux or macOS, you might be seeing a different set of instructions altogether. But like I said, leave everything to their defaults and finish installation. But here if I choose this option, get is actually going to add a path variable in system enrollment variables so that we can start using Git commands on Windows command processor. If you choose this option. However, it's not going to do that with an assumption that would only be using Git Bash. Again, we're going to talk about Git Bash, get gray in next lecture. Next, I'm going to leave this to default. Basically. It is asking if they want to use the existing OpenSSH or if you already have it installed some. You can just point to it. But we're going to use the OpenSSH that comes along bundled with good. By the way, openness that would essentially allow you to connect to the remote machine in a secure manner. More on it in coming lectures for sure. Leave this to default as well. Obviously, you don't understand what is combat or this checkout, so I cannot explain you anything about this right now. Leave it to default. Leave the default. Okay, this talking about git pull. Again, this is too advanced for you to understand. Just leave everything to the defaults. I'm British or you may not be understanding all the steps in here. Don't even try to understand it's not necessary. We're going to explore everything in coming lectures. It's perfectly normal. If you don't understand, that's perfectly all right. Trust me. Hit Next. Enable file system caching. Yes, we want to, that would improve performance. We can unselect this too and hit Install. Wait for a bit. Alright, I don't want to read the release notes. Head finish. Okay, we have now installed on our local machine. Let's go and verify. If it indeed got installed. I'm window open, Windows command processor. And then type in get. If you're able to see an output like this. That means get was installed successfully. And the reason we're able to run git command from Windows command processor is because somewhere in the middle of the installation process, we had asked to get to include path variable of get in Windows enrollment variables. Let me show you what I mean. Search for enrollment variables. Click on Edit System enrollment variables. If you go to path. Here you would see path to get library. So whenever you run command, something like that will just run. Windows OS is actually going to take a look at all these parts listed in here. And then it come across with this part where it has the code to do something with GET command. And hence we're able to see this output. If you remove this, we wouldn't be able to run any Git commands from Windows command processor unless we explicitly go to this directory and do that. Anyway, if all this sounds confusing, just simply ignore, trust me, you're going to understand everything in coming lectures. 7. 0106 Git CLI vs Git Bash vs Git GUI: There are basically three ways we can interact with Git. We can either use gets CMD or Git Bash or get GUI or graphical user interface. Gets CMV is nothing but the Windows command processor we use to run git commands. In fact, we had already taken a look at an example of the same in our previous lecture, where we were testing the installation of getting. The other option we have is to use Git Bash, which is a tool we had installed along with Git. Git Bash is similar to Windows command processor, except that we can use standard Linux commands to interact with good. This will come in handy, especially if you're coming from Linux background where you're used to running Linux commands. And now let's say that you are working from Windows operating system. You don't have to take that additional learning curve to understand Windows command in order to interact with Git. For example, in order to list down all the files in a particular folder inside Windows command line, use the command there. Whereas in Linux, you use the ls command to list all the files. If you're using a Mac or Linux, they both come with Unix shell. You don't have to install Git Bash. Git Bash is only meant for Windows operating system. If you're not used to either of these tools, then obviously it is always better to choose Git Bash over good cmd. And the reason being, if you're used to Git Bash, you can also work on Linux operating system at later point in time, if you were to. The third option we have is get GUI or graphical user interface. And as the name suggests, this tool will provide a graphical user interface to interact with Git. Now, I do have to mention that get gooey does not have support for all the features that get has to offer. We can do more with Git Bash or get CMD combat to get glory. That being said, good GUI has its own role as well. For example, if you'd like to take a look at the overall picture, or if you'd like to get a bird's eye view of the entire historical changes, et cetera. Then you might find it useful to use the get query compared to get that cash. However, in the rest of the course, we'll be using Git Bash as this is the best option. We might as well explore get-go way at some point in the course. But we're going to be primarily focusing on Git Bash, which is also the popular choice. 8. 0107 Basic Bash Commands: Let's take a look at some of the basic commands we can run on Git Bash to interact with the Windows file system. Now, if you're coming from a Unix or Linux background, you probably know all these commands. Feel free to skip the video. You don't have to watch the rest of the lecture. And for others you might be wondering why do we have these commands? Well, on Windows, we create folders. Take a look at what's inside it, or delete folders. We do that graphically that Windows provides us. However, if you want to do the same from Git Bash, we need to use these commands because Git Bash doesn't come with a graphical user interface. Now you might be having another question. Why do we need to interact with the file system using these commands when we can do the same on Windows? Well, the answer is, you can do it either way. But if you learn these commands, it might be helpful to you in the future. For example, if you were to work on Linux operating system, you don't have Windows OS there. You have to interact with the file system using these commands. And these commands are not difficult to learn either. They're actually pretty self-explanatory. For example, we have MKDIR stands for make directory. And as the name suggests, it will help you create a directory or a folder. And then we have CD stands for change directory. It will help you change from one directory to other directory. And this is the command we use to navigate within the file system. And then we have PWD stands for present working directory, which will just print the dietary on which we're currently at while working on Git Bash. If you ever wonder on which directory you're working in, then this is the command to run. And then we have Ls stands for list. And this would just list down all the files in a particular directory. This command combined with option hyphen a, list down all the files, including the hidden files. And then finally, we have our M stands for remove. And as you might be guessing, this will help us delete a folder or a file. Now, some of these commands would go with certain options. We'll explore them in just a while. I've created a test folder for the sake of this lecture. And this is where we're going to experiment with all those commands. First of all, let us launch Git Bash. You can launch Git Bash either from the Start menu or you can just simply right-click and click on Git Bash here, this would launch Git Bash in the current directory. You're going to see a screen that looks something like this. Let us start off by creating a new folder. So it gets the command that I need to use. It's MKDIR stands for make directory. And I'm going to provide the name of the folder or the directory that I wanted to create. Let's call it my app or whatever. So this has created a new directory in order to make sure that it has indeed created a directory. Let us run the command ls to list down all the files in the current directory. And sure enough we see the directory that we just created. We can also append an option hyphen a to list down all the files, including the hidden files. But at the moment, in this territory, we don't have any hidden files to show. But this command will come in handy in future, especially when we want to explore the gift directory, which has hidden. Now let us get inside the app directory. How do I do that? Because the command cd to change the directory. And I wanted to mention that directory, hit Enter and we're currently inside the MyApp directory. To make sure that we're inside this directory. Let us run the command PWD to check the present working directory, and this would print my app directory. Now let us go to the parent directory of my app. So how do I do that? We do cd space, dot dot slash. If you want to go to grandparent directory, then you just have one more dot dot slash. And that will do the trick. However, I just would like to go to the parent directory. Now let's do ls command to list down all the files. Now let's say I want to delete this folder, gets the command, it's RM, and the name of the folder. But this is not going to delete the folder. Well, it doesn't delete the folder because this user doesn't have the permission to do that. Or this folder might be having files in it. And it is asking us to delete those files first. Only then will it allow us to delete this folder? However, we know that this folder doesn't have any files in it. So it has to be the other reason. In order to work around this, we have to include an option along with the RM command, and that is hyphen r, f. R stands for recursive and F stands for force. Recursive would mean that we are saying, not only do we want to delete this folder, but also all the files in it? And effort mean force. In other words, we want to force delete the folder regardless of the permissions. I'm going to specify the name of the folder. And this time it does delete the folder. If we do ls now, it doesn't show that folder anymore. So take five to ten minutes and try to experiment and play with these commands. Basically just try to create folders, delete folders, take a look at what's inside the folders, etc. 9. 0108 What exactly is Git Commit: You've probably heard of git commit, but what exactly is it? Let's take a look. Imagine that you are playing a video game. And assume that you have made enough progress in the game that you don't want to risk losing. You save the game at that point in time by giving a meaningful message, you continue playing the game and make some progress. And once again, you feel like saving the game. And you do just start by giving a meaningful message. And if something were to go wrong with your game, you just take a look at all the list off saves you are made and load the game at a particular point. Now, you need to note that the save here is not actually a backup. It is kind of like a snapshot. For example, you cannot just copy the save file and take it to another system where the same game is installed and be able to load the game from that saved point. It's not possible. However, if this is a backup, you take backup of the entire game altogether. For example, if game is inside a folder, you would just copy the entire folder, take it to another system, and start the game where you want to start. Saved here is essentially like a snapshot, but not exactly a backup. Similar analogy can be explained with Windows restore points. You might be creating multiple restore points by giving a meaningful message. And if something goes wrong with your system, maybe a virus or something, I really wish that doesn't happen. But if something like that happens, you just take a look at all the list off restored once you have created, choose one of them and restore the system back to its earlier state. Just as you have restored points for Microsoft or save option for a game, you have git commit. For your project. You're going to make some progress in your project. For example, let's assume you have blogged on feature one. And then you feel like you've done enough to save the project or commit the project. You do just that by using the command git commit. And then you continue with the project. You work on another feature and then commit the project with a meaningful message. And if something goes wrong with your project, then get will allow you to go back to earlier state of the project or revert a particular file to its earlier versions, etc. Just like saved is not a backup in a game. Git commit is not actually taking a backup of your entire project, but rather taking a snapshot of your project at that particular instance of time. As in that you have created a project with all these files. And now you feel like you've done enough to save the project or commit all the changes to the repository. Now you can't just go and run the command git commit and mentioned all the files that you want to come at. It doesn't work that way. Unfortunately, there's an additional step involved before you come in. And there's a reason for that. For example, you could be having other files in the project which are not meant to be committed. You don't want other team members to be able to access these files. For example, it could be having some auto-generated files or you could be having certain files which are intended only to be used locally, but shouldn't be available to outside world. And that's where we have an additional step where you need to let get no motor all the files you wanted to track. Currently, all these files in your working directory are not actually tracked by Git. You need to explicitly tell it what are all the files you wanted to track. You can do that with the command git add. You want to use this command git add. And you'd mentioned all the files in this case, we're going to mention by layer file, file C and D and run the command that would essentially copy all those files into staging area. And this is when get will start tracking these files. Once you do that, you're going to use git commit command to sort of commit all the changes to a local repository, or sometimes termed as object database. And this is not the only case where you might be needing git add git commit. Let's take a look at one more use case. Imagine that you have couple of features to walk on. And you simultaneously worked on both the features and assume that feature one changes went inside file a and file B. And feature two changes went in file C and D. Now we want these two features to be going on to different commits, not in a single comment. How do we do that? If there is no concept of staging? And if we were to use the command git commit, that would commit all these changes, we don't want that. So with git add command, we'll first add all the files related to feature one. And then we'll commit the changes with a meaningful message, just as we are given a meaningful message while saving a game. We're also going to do the same in gets off comet. Now, once you're done with that, we're going to add file C and D and commit as feature to. Over a period of time. We're going to maintain all such comments in our local repository. And that way we'll be able to take a look at all the historical data, would be able to reward our project back to its earlier state. Or we can do what the particular file to a particular version from its past history. Or we might want to take a look at the difference between the current version of the file and its earlier versions, so on and so forth. We're going to explore all that in coming lectures for sure. And eventually we're going to push all this changes to a centralized repository like GitHub. And that's all other team members would be able to access your changes and also all your comments and historical data. However, that's the topic of another chapter. I also should mention that when I started using Git, I joined a local GitHub community. Now asked them this question. Why do we need to have a couple of steps to commit the changes? Why can't we just have a command that looks something like this. We're going to mention git commit hyphen m. And then you're going to give a message. And then you're going to list down all the files that you want to commit that might be corresponding to feature two, for instance. Well, I didn't get any satisfactory answer from them. In fact, if you talk about other version control systems like Mercurial or subversive, they don't have this additional step of adding the files before committing. 10. 0109 Initilizing the project and Exploring dot git folder: Let us see what it means to get initialized a project. In order to understand this better, let us assume that I've got a freelancing contract, whereas asked to create a web application for my client. Inside my system, I've created this folder with the name my app, inside which I'm going to introduce all the files required to create a minimal working application up and running. Now I could create all those files using the new option here. But I'm actually going to do it using Git Bash just so that you'll be familiar with all those Linux commands. And the commands that I need to use is called touch. And then I'm going to specify the name of the file. For simplicity, I'm just simply going to call it as one dot TXT. Now, obviously it doesn't make sense to have a TXT file to write the source code. But we're not really interested in creating applications here we want to learn, get into, make certain assumptions. Similarly, I'm going to create two rod dxdy. I got the name wrong. And three dot dx, dy. Let's rename this to two dot TXT. So I've got all these files created. But currently none of these files are actually managed by Git. For instance, if I were to run the command git commit now, it's going to throw a message saying not a Git repository or any of the parent directory is. So we need to let it know that it needs to manage your project. And the way you tell it is by using a command git in it stands for initialization. Once we get initialize the project, we're essentially asking get to setup a written, it needs to set up inside our project to now start managing a project. I'll create versions on we ask it to. And if you notice, it has actually created a hidden folder with the name dot get. This is where we have this staging area that we've talked earlier. And this is where we have the object database that were talked earlier. In case if you're not able to see this folder, then you need to enable the option to show the hidden files and folders. Inside Windows, you need to go to the View tab, click on Options, click on Change folder and search options. And once again inside the view tab, you should be able to locate that option to enable or show the hidden files. And here it is. Click on this option that says show hidden files, folders and drives. Hit Apply and Okay, and you should be able to now find this folder. Let's take a look at what's inside it. Now, obviously, it's not really worth going deep and trying to understand everything what's inside here. We will explore some of these in the rest of the course as and when we find it appropriate. But for now, I'm just going to give you some overview as to what's inside this folder. We have this hooks folder inside which we have bunch of scripts. These scripts would defined what needs to be done before and after a particular event. For example, we're already aware of the commit event. And then we have the script with the name pre-commit. As the name suggests, it does something prior to executing the actual commit logic. So get my run this script prior to executing the commit logic. So we might be having things like validating the syntax, et cetera. If you're really curious as to what's inside the scripts, you can right-click and open it up with Notepad Plus, Plus. And just go through all these comments and try to get a sense of what it is doing. But I don't recommend you doing it. Don't confuse yourself. Then we have the input folder inside which we have this exclude file. Let's open it up with Notepad Plus, Plus. If there are any files in your project that you don't want to consider, this is where you would list them down. You can also use patterns. For example, you can say star dot log. And now get would ignore all the files with any name, but has the dot log extension. Just an example. And by the way, exclude file is something that is local to a computer. And whatever you add in here is only applicable within your own depositor, inside your local system. If you want to have exclusions across all the team members, then there's a separate thing for that called gitignore. We'll talk about it in coming chapters. Next, we have the objects folder. This is where good foods store all the historical data or the version history. This is what we're referring to as the object database. Well, currently this folder does not have a lot of data. But once we make few comments, you're going to see this folder getting populated. You're going to see a bunch of folders getting created. Inside objects folder. We have the ribs folder, but that does not talk about it because to understand this, you need to know what is a commit object, hashing, et cetera. So we're going to skip it for now. Conflict file is something we'll explore in the next lecture. The description file has something to do with Git web. And since you don't know get web, it doesn't make sense for me to talk about it. Right now. The head has something to do with branching. So we'll talk about it. When we talked about branches. Let's move on. One thing I should also mention is that get in it is a safe operation. Meaning that let's assume that I've worked on my project for a while and I've made a few comments and then accidentally assume that I run the command once again, inside our project. This is not going to do any damage. Everything would remain as it is, as if we didn't run this command at all. However, if you delete this folder, then that's going to cause trouble. You're going to lose all the historical data, all the version history, et cetera. And then you would either need to reinitialize the project, but running the git init command and start from scratch. Or you need to check out the project from the centralized repository, which we'll explore in coming chapters. But as a rule of thumb, you should always remember not to mess with this folder unless you know what you're doing. The fact that it is hidden by default should tell you that it is not intended to be used by developers like you and me, but to be used by itself. However, there might be instances where you might need to bring some edits or do something inside this folder. For example, we've already talked about the info exclude file, where you might want to add some exclusions. But otherwise, in most of the cases you don't want to mess with this folder. Just leave it to get. 11. 0110 Configuring Git Credentials and exploring local global system configs: Okay, let us see how we can configure Git credentials and try to understand its actual purpose. We now have a project initialized by get with a bunch of files. Let us now try to run the command git commit and see what happens. You get 12. Kindly ask you, please tell me who you are. Now. The water is asking local commit changes for you, but who the **** are you? And it has also provided instructions as to how we can introduce ourselves to get is by running this command. But this is not just about you introducing yourself to get this actually real purpose of you configuring these credentials. For example, let's say that one of your team members received a defect or a bug assigned to their name, saying that we're not, the feature is not working as expected. In the process of analyzing the problem, they want to take a look at all the historical changes on that file. And then they come across with a change introduced earlier, which seem to have caused the problem or would seem to have broken a feature. Guess what? They're going to get to know the name of the person and the email address of the person who made those changes. They're going to contact them and ask them to fix the bug. But how does get no. All this it is when you configure these credentials inside, you get, when you make a commit and push all those changes to the centralized repository, which is going to be GitHub. It will also store this information as to who has done what changes, and it includes your name as well as e-mail address. So if you introduce good code, somebody will come back and praise you. Are. If you introduce bad code, somebody will come back and blame you. In most cases it is always the blame anyway, but no comments on that. So let us see how we can configure the credentials and get has already provided us how to do that. So let's use that command, git, config hyphen, hyphen global. When we set this global option, what this means is these credentials are available across all the projects, all the good projects that you create inside your system pertaining to this particular user. If you said this two system, for example, then these credentials would be a valuable system-wide. Meaning every user in the system will have all these credentials applicable. We also have one more option that says local. That means these convicts are only available for the current repository where you're working on. So first let's try with local. Maybe I'm going to first set the name. You can set any name of your choice, but it has to be your name. And I'm going to hit Enter. And I'm going to set email as well. Okay, now let's take a look at where these are actually populated. So that's inside the folder. Remember not earlier lecture, I mentioned that we'll talk about this config file. Well, this is where all those credentials would be set. Now let's try to set these credentials at the global level. This time, this wouldn't be populated under Users directory inside your C Drive. Let me pull that up. So inside the user's directory, you should be able to locate the Git config. And this would get reflected over there. And similarly, if you were to set the system-wide credentials, you can do that. I don't expect your computer to be used by multiple people and they're all contributing to your work. But anyway, let's set this up for system is that though you need to have permission. So that doesn't launch get from the start menu as an administrator. And then we'll be able to set the credentials, get config. I'm sorry, The supposed to be system-wide changes user name. I'm going to say this has walked and these would be reflected inside the program files. Let me take you there. Inside Program Files, get ETC directory. You're going to see the Git config file. And this is where the credentials would be populated. By the way, I should also mention that local credentials will override global credentials. And global credentials will override the system level credentials. So get, we'll try to get the local credentials fast. If they're not available. It will try to search the global credentials. Otherwise, the last option would be this system credentials. If none of these are set, then obviously are going to see an error. You can also take a look at the credentials by running a command git config list. Somewhere here, you're going to see the name and email like cell. You can also give an option to see a particular level of credentials, let's say local for instance. And you can also be more specific about what information inside Config. You want to take a look at, going to take a look at username for instance. And it's going to print the value of it. 12. 0111 Staging and Unstaging and checking status: Let us see how we can stage an unsteady files inside Git repository. And as I've mentioned before, we need to stage files before we plan to commit them. So currently we have three files inside our working directory. Let us plan to commit them. Let me expand the window so that you get a better view. Also, let me type in the command clear to clear out the screen so that we get a fresh view. I'm going to do an ls to list all the files. And we currently have three files. If I tried to do git commit, now, it's going to complain us saying we have untracked files inside of our project. We need to have at least one file. Tract are going to have at least one file in staging area to be able to commit. And that's what it is complaining. Now how do we save these files? Gets the command, Well, good has already given us a clue. It's good at. So let's do git add. And I could just list down all the files I wanted to commit. For example, one dot TXT space to dot TXT, so on and so forth. This would be useful if you want to be select two as to which files you want it to come in as part of a particular feature. However, in this case, I'd like to commit everything. So I could just use a wildcard character style. I can also use a pattern. For example, I can say star dot TXT, and this would stage all the files with any name that has dot TXT extension. So let's run this command. This is what we need. So this has now staged all our files in staging area. How do we make sure it has staged all our files? Well, there's a command to check to see the status that git status. Git status command will show us a list of untracked files, list of files that are being tracked, files that are modified, et cetera. This command will come in handy to check the status of our project as we progress in this course, you'll understand more about this command. So after running this command, our files are listed under changes to be committed. And it has also turn the color of these files to green, representing that these files are now being tracked or these files are in staging area right now. What it says in earlier case where all these files are listed under untracked files and are marked red. Now, assume that I wanted to remove one of these files from staging area, maybe because I've accidentally added it in here. How do we do that? Well, God has already given us a clue as to the command we need to run to on-stage a file that's get RM with hyphen, hyphen cached option. Whenever I say cached are indexed or staged, we all mean the same thing. Keep that in mind. So get RM hyphen, hyphen cached. And I'm going to list on the files that I wanted to onstage. If I want onstage all the files, I could use a wildcard character like so. And this would onstage all the files. Let me do that. So this has unstated all our files to make sure that it has onstage all our files. Let's use the git status command. And as you can see there back to untracked files section and there once again marked red. Let's add them back again. Let me this time create onstage a single file, maybe two dot TXT. You need to make sure that you use this option cached. If you don't use this option, then this command will have a different meaning, which we'll talk about in coming lectures. This has on staged two dot TXT. Let us know, check to see the status of our project. And as you can see, two dot TXT is now listed under untracked files. But as the other two files are listed under changes to become at it. So take a moment and try and experiment with these commands to stage an unsteady files and check this data simultaneously. Don't commit the changes just yet. We're going to talk about it in next lecture. But don't hesitate or be afraid to experiment with all these commands you might be feeling these comments are pretty simple and straightforward at this point in time. But as we progress in this course and as I introduce more and more git commands, you will start to feel that they're very confusing. So the only weapon you have to avoid that confused state of mind. His practice, I cannot emphasize how important it is to practice all these commands, otherwise, you will soon confuse yourself. See you in next one. 13. 0112 Understanding Commit with multiple usecases : Let us see how we can commit our changes to Git repository. By the way, when I say Git repository, I could mean our project folder with dot git folder. Or I could also mean the object data store that we've talked earlier. It depends on the context. To avoid the confusion, I'm going to call our working directory are our project folder as Git repository. I'm going to refer to the object database as the object database just to avoid confusion. So currently we have all these files in place. Let us make sure all these files are staged. I'm going to do git status. We have one file which is not staged. So let's do git, add two dot TXT to stage it. Let's do git status once again. And we have all our files staged. I'm going to say git commit hyphen m. And then we're going to provide a meaningful message. Why do we need to provide this message? Well, basically describes the changes that you're committing to it later point in time, if you or somebody else in your team, what to take a look at all the historical changes or historical commit. They get to know which committee as well by looking at its message. For example, you could be committing changes to fix a bug or add a feature. As a good practice. In real-time applications, we follow a specific format for this message. The first is going to be combination of alphanumeric characters, which is essentially a defect or a feature ID that you pick from your defect tracking tool. If you're working for an organization, then you might be having a defect or feature tracking tool. You pick that ID and enter it over here. For example, it could be something like WI, some numeric codes. W stands for work item. It could be something else for you. And then you're going to produce descriptive message. And even this message, would we pick from the title of the defect from the defect tracking tool? I'm going to say my working app or whatever. Let's hit Enter. And all the changes that were staged would now be committed. And in order to make sure that we have all the files committed, let's do git status. And it doesn't show anything, which means we don't have any files to become addicted. Now let us go ahead and make a modification in one of the existing files in our working directory. For that, I'm going to use the command echo just to fill one out the files with a text. My text in file one for instance. And I'm going to dump this message inside one dot txt file. This command is equivalent to opening the one dot TXT file and entering the text, my text in file one. Let me hit Enter. Now I'm going to use the cat command to see what's inside the one dot TXT gesture I showed you that we have this message over there and it prints out the text inside OneNote dxdy. All good. Now this is a change that we've introduced, which means we need to stage this in order to commit this. So let's do git status once again. This time it's going to say we have one file which is modified. So we need to do git add to add this file and bring it to staging area. Git status. It turn green, which means it is ready to be committed. I'm going to once again use the commit command. Commit the changes. Let's remove the defect ID for the time being. Let me just give a meaningful message. Modified file, one, for instance, hit Enter, get status. And sure enough, we have our changes committed. Now let's consider a case of deleting a file. So for that I'm going to use the command RPM stands for remove. And then I'm going to specify the file name. Let us get it off to dot txt, different stance. Now this command is not specific to get, this is a typical Unix command. Hit Enter. I'll do ls to see if it got deleted and indeed it got deleted. Now this is a new change which is introduced in the project. Guess what? We need to stage it and then let them know that we have deleted the file. And so it gets reflected in the object database as well. So git status is going to show that file has been deleted, but this change is not staged. So git add dot dxdy. Good status. And we have changes which are ready to become edited. Once again, git commit with a meaningful message. This time, let me not enter any message and hit Enter and see what happens. Well, it would open up text editor that we had chosen while installing Git. In my case, it has Notepad Plus Plus for you it might be something else. Here, we need to enter the message which we would otherwise enter with hyphen m option when to say it deleted file. To save the file and simply close it. And it has committed our changes. We use the RM command with the mood, the file. And then we had done git add command to stage those changes. However, we can do these two steps in one goal is by using the command get out from this time instead of just RM, I'm saying get RM. This will not only remove the file, but we'll also stage those changes to staging area. Let's delete three dot dx, dy for instance. I'll do ls. And as you can see, file got deleted. But if I do git status, unlike in case of RM command, this time the changes are already staged and you can directly commit the changes. Git commit, hyphen them. Deleted three file. Now let's take a look at all the list of commits we have made by running the command git log master. Master is the name of the branch and is also the default branch. We're going to talk about branches at later point in time. But for now, just blindly run this command to see all the list of commits you've made. The most recent one would be shown on top. As you can see. We have our first commit, but my working app message. And then we modified file one, we deleted files to be deleted. Three file. I also can see the author who has done that. It is mean in this case for you. It would be whatever you've entered while configuring the credentials. When we have centralized repository and when we have a team working on a project, you'd be able to see all the list of commits done by multiple team members. And if you were to spot a commit which is causing trouble or which might be breaking a feature. You can get hold of the author by writing an email to them. 14. 0201 Sha1 Hashing Algorithm: Let's forget about it for a second and let us try to understand what is Chavan hashing algorithm. The siobhan hashing algorithm, or sometimes referred as hash function, would take any arbitrary amount of data as input. And it's going to give us a 40 character hashCode has an output. The size of the input doesn't matter. It could be as small as one byte, or it could be as large as one GB or even one TB. But the resulting output is always going to be a 40 character hash code. Even if the input is just one single alphabet, you're still going to see a 40 character hashCode as output. Here are some of the characteristics of hash function. Same input would result in same hashCode, no matter how many times you execute, it may provide the same input that's going to result in the exact same hashCode. You cannot generate data from a given hash code. Although it is possible to convert data to a hash code, it's not possible the other way. I mean, if I give you a hashCode, it cannot generate data out of it. It's really difficult to find another input which results in same hashCode, but it's not impossible. You could have another input that might result in exact same hashCode. But the probability of finding it so that you don't even have to worry about it. Here's one other use case where hashCode might be used whenever we use the registers for your website by entering the username, password, and other details. Instead of storing the password and draw text format inside the database, we're going to store the hash code of that password so that the next term user tries to login. We're going to again run the hashing algorithm on the password that they enters. And then we're going to see if the resulting output would match with the one in the database. If they both match, the user would be authenticated and would be granted access. The benefit of storing hash code instead of storing the raw password in textual format is that if a hacker hacks your system, they get access to hash codes, but not the actual passwords. They cannot do anything using the hashCode. For example, they cannot login using the hashCode on behalf of a user. All the hashing algorithm is used as a security measure. You get to use a set for a different purpose. And it is to uniquely identify various objects and get. And we're going to talk about it in next lecture. Now let's try to generate hash code from Git Bash using the git commands. The command to run is good hash object, but before that, let us use the echo command with some text. I'm going to use pipe character and then say get hash object standard input. By using the pipe character we're telling whatever is the output of this command would be the input of this command. Essentially, we are trying to get the hashCode of this particular text. Let's hit Enter. We got a hashCode for that text. And no matter how many times I execute the same command, we're going to see the exact same hashCode. But if I make even a small little change, the resulting hash code would be entirely different from what we've just seen. For example, let's say I just added one character and hit Enter. You'll see that these two hash codes differ significantly. You're going to understand more about hashCode, incoming lectures. 15. 0202 Git Internals (All about Object Database) Part 1: In order to better explain how good managers and stores the data inside the object database. I have deleted everything inside our project. So all our commit past history, all the changes we've had introduced are now gone for good. What we have here is essentially a brand new directory. And I'm now going to launch Git Bash here and create a bunch of files and directories. I want to create a couple of files in this folder. So I'm going to use the command touch one dot dx dy and dx dy. This has created a couple of files. In addition to this, I'm also going to introduce a sub directory inside our project. It gives the command to create a brand new directory. It's MKDIR stands for make directory. I'm going to name it as assets. So we have assets that are recreated. Let's go inside it and create bunch of files in there as well. I'm going to create, I want to use the command touch one subdata dxdy, substance or sub directory, just for our understanding. And two sub dot TXT file. Let's also put some content in this file. Let's go back to the parent directory, which is our project root directory. I'm going to use the command echo. Next-gen file one. We're going to populate it inside one dot TXT file. And similarly, we're going to populate some text inside the other file, stool, dxdy. One sub, this is going to go inside one sub dot dx dy, which is inside the assets sub-directory. So here is our directory structure. We have assets directory and couple of files inside the root project directory. And inside assets that are true. We have these two files. Currently this folder is not get initialized. So let's do just that. Get in it to get initialize this project. And git add all the files. Git status to see the status. And as you can see, everything is staged. Now let's commit the changes. Git commit. M. My first comment. This should work. In the next lecture, we're going to understand the different object types we have in Git and how all these files are stored inside the get object database. I'll see you in the next one. 16. 0202 Git Internals (All about Object Database) Part 2: Let's talk about how good it actually stores the data inside the object database. In our previous lecture, we had created a project with bunch of files and we committed those changes. And here is the project structure we had. We have the my app folder, which is the root project directory. Inside of which we have one dot takes you to dot TXT and also a subdirectory called assets. Inside the assets directory, we have one sub dot dx dy and dx dy. Now let's take a look at how these files are actually stored inside the database for which we need to understand various types of objects that get has. First we have the Blob object for each and every unique file that you come at. There's one blob object created inside the database. Each of the blob object would store the content of their corresponding file. For example, we might have a Blob object created for one dot dxdy with all its content. Each of the blob object will also have a unique hash. And as you might have guessed, this hash would be generated using Siobhan hashing algorithm. And the input of that algorithm would be the content of the file. It is not really using Siobhan algorithm to secure the application or something. It is using it to create a unique identifier for its objects. And the content that gets stored inside the blob won't be in human-readable format. It will be stored in compressed format. So I'd get can efficiently store, manage, and retrieve it. However, get also offer certain commands using which would be able to read the content inside the blob. We're going to explore that in coming lectures. Now, since there are four files which we had committed earlier, there are going to be for blobs created inside the database along with their corresponding contents of those files. Next we have three object. Tree object would correspond to each and every director in the project, including the project root directory. And just as with Blob object, tree object is also going to have a unique cache to uniquely identify a particular tree object. In addition to that, it will have references are essentially it will maintain the hash codes of other blob objects or three objects or combination of both. For example, we have a couple of folders inside our project. And so they're all going to be couple of three objects created for each one of these directories. So we will have a tree object created for the assets directory. And inside that object it will hold the references are hashCode of its files. In this case, this tree object would hold the hashCode OPT sub one dot TXT and subdued or TXT. Essentially these are the hashes of the blobs that corresponds to sub one dot T extends up to dot TXT. And then we're going to have another tree object created for the parent project directory. And it's going to have hashCode off its own files. In addition to that, it will also hold the hashCode of the sub tree, which corresponds to the assets directory. And of course, each one of these three objects would have their unique hash code to uniquely identify them so they can be referred from some other objects. Next, we have the commit object. Once again, this will have its own unique hash. And this hash will be generated based on the commit information, like the author name, email address, the message that was entered, the time at which commit has happened, etc. And commit object would hold the reference or hashCode of the parent tree. In addition to that, it will also have information about the author name, email address, the message that was typed while committing, etc. And except for the very first combat, the commit object will also hold a reference or hashCode of the previous comment. You'll know the significance of it in coming lectures. For the changes that we had just committed. This is how it would store the information in the database. So we have three objects that corresponds to each and every director in the project. And then we also have Blob objects that corresponds to each and every file inside the project. Now it's not necessarily that if you have ten files created inside your project, we would have ten blobs created inside the object database. It doesn't necessarily have to be that way. For example, if you have two files having the exact same content, and they both would generate exact same hashCode, for instance. Then get will not create two different blob objects for that, it will just create one blob object and refer to it instead. Anyway, more on it in coming lectures. 17. 0204 Git Internals Viewing and reading Git Objects: We have theoretically understood how good it actually manages and stores the data inside the object database. Now let's take a look at it practically in order to explain things better. I'm also going to show you a graphical representation of what we're doing right now on the right-hand side of the screen so that you'll have a better picture as to what we're doing. So currently we just have one commit. Let's take a look at it. So I do git log to take a look at all the list of commits. Currently we just have one. And as you can see, we have author information, date, and even the commit message. In addition to that, we also have 140 character hash code. Can you guess what this hash code is all about? Well, here's the hashCode of the commit object corresponding to this commit. Now how do we take a look at the content inside this comet object? Well, this hashCode itself will give a clue as to how we can navigate to this commit object. Let me show you what I mean. I'm inside the project directory. Let me enlarge it for you. I'm going to go inside the dot git folder. And guess which folder we need to get into. That's objects folder. Now here we have bunch of folders which were not existing before we committed the changes. Now if you look at the hashCode and take out the first two characters, it says 95. We need to go inside that folder. And then you see a file with the name, which is essentially the remaining characters of the hashCode. So we have 95 ECE, so on. 95 is the directory name and the rest of the characters is the name of the file. And this is what we're referring to as the commit object. If you try to take a look at the content inside it using a Notepad Plus, Plus, you won't be able to read it because it will store it in a different format that is not readable by us. The only way you can read the content in it is by running the command get kept file. And then you're going to provide the option hyphen P stands for pretty print. And going to provide the hashCode of the object that you want to pretty print. I could copy the entire hash code, or I could just copy the first few characters and pasted here. And this would print Watson inside the comet object. If you'd like to take a look at the type of the object, the option for that is hyphen d to print the type. And this has come at object. Let's pretty print that object once again. So here, as I've mentioned previously, you have information about the author computer and even the commit message. In addition to that, we also have a hashCode, which is actually the hashCode of the parent tree object. So let's take a look at what's inside the tree object. And I'm going to use the same command to pretty print what's inside the tree object. I can just copy first few characters. Paste it in here. And if you hit Enter, you're going to see what's inside it. Since we have to go back to the root directory, we have one subdirectory and couple of files. And if you take a look at what's inside this tree object, you have couple of blobs. Each blob would correspond to individual file. In this case it's one dot dx dy and dx dy. And then it is also pointing to another tree, or it is having hashCode off and other tree or the subtree. So we can go inside the sub tree as well. Let's do that. Gets the output. It's going to be the blobs off the two files inside the subfolder. One sub dot takes into sub dot TXT. And by the way, you can locate these objects inside the objects folder. Just as you had located the commit object. It is no different. Since I'm the objects folder. You will find a folder. So this is the sub tree object we were talking about. And similarly, you can also find the blob objects. For example, let's talk about this blob. It starts with 99, so we're going to go inside that directory. And this is a Blob object. Let us try to pretty print this blob object and we should be able to see the content inside it. And once again, if you were to open it with Notepad Plus, Plus or something, you wouldn't be able to read. And you see the text that's inside this file. So that's how we essentially get stores the data inside the object database. And understanding of this is very important for you to understand how the topics we're going to discuss and coming chapters. 18. 0205 How Blob Objects Behave: Let's talk about Blob objects and how they're managed inside Git repository. Imagine that I've created a brand new project with the following file, one dot TXT, and it has the following text in it. Hello from getting. Now the moment I add this file onto this staging area, get will actually try to generate a hash code out of the content of one dot TXT file. And get will then check to see if we already have any objects in object database that corresponds to this hash code. If there are none, then it would go ahead and create a Blob object with all the contents of one dot txt file, of course, n compressed format. Now assume that I've created one more file, say two dot TXT, with the exact same text as to the rough one dot TXT hello from getting, once again, assume that I've added this file onto the staging area. Getwidth. Once again, try to generate hashCode out of the contents of two dot TXT file. And this time get, we'll notice that we already have an object that corresponds to this hashCode. So get won't create another blob object. The reason for this is quite obvious. Why would we want to create the exact same blob object when we already have one. Why don't we just use the existing one? It makes sense right? Now let's take a look at all this in practice. For the sake of this example and avoid any kind of conclusion. I've created a new folder with the name Tests tab. And here's where we're going to experiment and see what get blobs can do for us. So let me launch and get bashed in this folder. First things first, let's get initializes the project. And let me go ahead and create a file with some content in it. I use the echo command. I'm going to dump this message inside one dot txt file. This command will not only create one dot TXT file module also populate it with this content Hello from getting. Now let's get inside the objects directory and see how it behaves. Let me state this file, one dot txt, git add one dot dx dy. And the moment I do that, we see a new folder getting created inside objects directly. Guess what this file is? Well, this is the Blob object for one dot TXT file that we've just created. So yes, blobs are created when new stage the file is not necessarily when you commit the changes. When you commit the changes it will create the comet object as well as the three objects that corresponds to bunch of blobs. In fact, that's the purpose of commit operation. It is to create a snapshot, saved the project at that particular instance of time. We're going to talk about snapshot in next lecture. Let's go back. Now let us see what would happen if I were to create another file with the exact same content. As to that often dot TXT, I'm going to use the same command. But this time I'm going to populate the same message into dot TXT file. Let us stage that file. I'll do git status. And we have these two files staged. But if you notice, there is no new object created for two dot TXT. And I've already explained you the reason for that. Since we already have a Blob object with the exact same content, get does not go into create another object. In other words, the moment we added the extra under the staging area, get tried to generate the hashCode of this content. And it has check to see if we have any existing objects in the database that corresponds to that hashCode. For two dot TXT, we do have existing blob and so it didn't create another block. Same principle is applicable even if you were to modify a file. For example, let's say that I wanted to modify the text inside to rock dxdy from file to for instance, we're going to replace the text inside to dot TXT file. Let us stage this file. Now, can you make a guess if we're going to see a new folder getting created inside objects folder, the answer is yes, of course. We have a new blob object created because this content right here is unique and there is no existing blob object for this. Let us also create one more file, three dot TXT file with the same content as to that often dot TXT. And let's stairs that file git status. And we have these three files to be committed. One dot dx dy and dx dy, or having the exact same content while do route dxdy is having a different texture. Now, let's commit the changes. Well, this is not offers, but whatever. Let's hit Enter. And as you can see, we have both commit as well as the tree object created as well, right after we come into the changes. Let's now take a look at what's inside the tree object. I will get log to get hold of the hashCode of the commit object. Git cat file item B. Let's check what's inside this tree object. So both one dot dx, dy, as well as three dot TXT, should be pointing to the exact same blob object. If you notice both one dot TXT entry or dxdy are pointing to the exact same blob object. Whereas for two dot TXT, it's a different Blob object. 19. 0206 Garbage Collection and Pack Files: Now you might be having a question. Every time we add a file or modify a file and bring them to staging area, we're going to see the blob object's getting created inside the object database. And get won't even delete them. Even if you were to unstable the files from the staging area. Is it efficient to do so or is it taking up too much of space? The answer is, it's not completely efficient of course. But good has this concept of garbage collection, which happens periodically or when you run certain commands, like get pulled for instance, we're going to talk about git pull, git push commands, incoming chapters for sure. But there are certain commands which will also trigger garbage collection. The concept of garbage collection is somewhat similar to garbage collection in other programming languages. For example, we have garbage collection in Java programming language wherein all the unreferenced objects would be destroyed. And same as the case with Git. It's not a 100% efficient for sure, but it also has mechanism to efficiently manage the objects. In fact, we can run the garbage collection manually. Let's do get GC. And if you notice how the objects which were existing before are no longer existing. Now, does this mean that everything has gone for good? The answer is no. We still have all of that. For example, if you run this command, we're still going to see how that object information and you can even read the content inside this blob objects. Now how is this possible? We don't have those object folders, but still were able to read those objects. Well, it's inside this back Directory. Essentially that garbage collection operation has further compressed all of those objects into single pack file. We also have idx, our index file. And this will tell which object is located in which back file. Currently, since all project is very small, we just have one single pack file. But as we have more and more files introduced into a project, you're going to see new pack files being introduced. An index would come into picture at that point in time. But anyway, this is not something that we really need to worry about. You can also verify Watson inside the PAC file. Let me launch Git Bash in this folder. And the command to use is get, verify back, hyphen v. And then I'm going to specify the name of the packed file, and this would print all the objects in it. One thing I should also mention is that technology is addictive. If we want to learn everything. Sky is the limit as to how deep we can go and understand each and every concept. But is it worth it? That's the question. You don't really want to learn everything out there. That's just simply not worth it. Because we already got a lot of things to cover and get is only the starting point and your DevOps journey. For me as an instructor, I need to know and research about everything. What good has to offer so that I can filter out what is needed and what is not needed for you. In fact, I'm hesitant to even talk about these concepts, but I felt that understanding of this is very important to understand all the future concepts we're going to talk about incoming chapters. But otherwise, I'm hesitant to talk about all these concepts which doesn't play any role in your Gettier. I can do that if I want to. I can just teach you things just to prove that I have knowledge on that. But that doesn't make sense to you or to me. My job is to make your job easy, not complicate your job. And I would rather prefer and try my best to teach you only the stuff that are absolutely needed for your job. You need to keep that in mind and don't try to learn everything. That's one of the biggest learnings I had in my career. I just tried to learn everything. In fact, technology is very addictive. The more you explore, the more you want to know more and it's not worth it. It's sort of like an entertainment in itself, in an odd way maybe, but it's for me. I have to take that pain not to you. 20. 0207 Git Snapshot What it means to take a snapshot: Let's try and understand what is a good snapshot. Earlier we had created a project where we had couple of files in the root directory of the project. And then we also have sub directory inside which we have couple of more files. If you could recollect from our previous lectures. This was the object structure we had when we made our first commit. Let me simplify this diagram so that it looks more compact. Now let us assume that I have introduced another file, c3 dot dxdy with the following text hello from getting. And I kept this inside the root project directory, stays this file. And then I committed the changes. Now can you visualize how the objects structure would be? For the second commit we make? Do you imagine something like this? So we have a new blob created for the newly introduced file. In addition to that, do you expect get to create Blobs for each and every file in the project? The answer is, of course no. Instead, git will create a blog for the new file. And the root tree object of the new commit will hold the hash of that new blob. And for all the other files, since they remained as is and are not modified, git will just simply refer to their existing blobs and three objects. In essence, the contents of the tree object and second column, it would be exactly same as the condenser of the tree object in our first commit, except there'll be one additional entry for the newly introduced file. In addition to that, they commit object will also hold the difference or the hashCode of the previous commit or its parent come at. You will know the significance of this in later chapters. So what is this snapshot here? Well, essentially every time you make a commit, you're taking a snapshot of the state of the index or the staging area at the time you make the commit. It essentially captures what every file looked like at the time you make the commit. If you were to go back in time to one of the previous commit, git will have the ability to restore all the files in your working directory to what they were when you made the comment. How is that possible? It's because of the snapshot. Now let's see all this in practice. I'm inside our good old my app folder. Let me go ahead and create a new file. So we have three dot dx, dy with some text in it. Git add git commit. Second commit. Finally, we're making a second comment. Now let us go ahead and explore the commit and three objects. I'll do git log to take a look at all the list of commits. And by the way, talking about the parent combat, when we run this command git log, it has displayed the details about our recent commit. And then this comment object is having the details of its parent commit, which is this. And so git will proceed and display its details as well. For this commit though, since this is the very first commit we made, it doesn't have any parent commits. And so this command will stop executing. Anyway, you'll understand more about parent commits and coming chapters. So let's go ahead and explore what's inside out. Recent commit. Get kept file, hyphen P. And as you can see, we have the hashCode of the root tree object. In addition to that, we also have the hashCode of the parent commit, which is this. And then author information, et cetera. Let's see what's inside this file. So here are the contents of the tree object. Let's compare it with the tree object of our first connect. If you notice, the hashCode of the sub tree object is exactly same. Hashcode of one dot dx dy and dx dy are exactly same except for the newly introduced to file three dot dx dy. So that explains. 21. 0208 Time travel with Git: Let's see how we can time travel would get. I mean, it I'm going to prove it to you in just a while. Let's say that you walk down feature one and you commit all those changes as part of your very first commit. And let's assume that all those changes went inside one dot TXT. And then your client says he needed another feature in his application. So you want to take and work on it, make another commit, and assume that all those changes went inside to dot TXT file. Once again, your client comes up with a creative idea. He needed one more feature in his application. And once again, you work on that feature, make another commit. And then let's say that you've introduced three dot TXT where you have all those feature three changes. Now let's say for some reason client has decided not to have feature three for whatever reason. And that he wanted to go back to previous version of this application. So how do you revert all the feature three changes? Well, in this example, it's quite easy. You just delete three dot TXT file and then you make another commit. However, as we discussed in one of our previous chapters, diverting changes is not an easy job because in real-world applications, you might be having changes scattered across multiple files. And it's really hard to revert all those changes without messing things up. You might end up breaking features which are working earlier. Fortunately with get would be able to go back to previous working copy of our project. Now I should also mention that whatever the approach I'm going to talk about to go to previous version of the project is not actually the recommended approach. The recommended approach is to use branches, which we'll talk about in next chapter. And in the next chapter, you will also understand why this is not the recommended approach to divert your changes. But for now, let's take a look at this in action. 22. 0209 Time Travel in Practice: Okay, let's see how we can time travel and get with a quick example. And once again, in order to avoid confusion, I've just cleaned up everything inside the desktop folder and we're going to do everything from scratch. Let me launch and Git Bash. My plan is to make three commits. And we assume that each comment would correspond to individual features. Get initialized the project. Touch one dot TXT, git add. We're going to stay as that file, git commit. And let's call it whichever one. We're going to repeat the process for feature to add as well. Let's call it two dot TXT. Git add two dot TXT and git commit. Feature two. Let's do one last commit representing feature three. And git commit featured three. Now let's do git log to take a look at all the list of objects. Let me enlarge this folder so that we can simultaneously take a look at what's happening here while we run the commands. So currently we have these three files. Now, let us assume that I wanted to reward and go back to one of the previous versions of the project. Let's say that I wanted to go back how my project looked like. I made feature to come at. The command I need to use is actually switch. Now, do take a note that this command may not be working for you if you have older versions of Git installed. So download and install the latest version of Git only then will this command walk. If you're still insist to use earlier versions of gaped, then there's another command called git checkout. You need to type this. And if you have the latest version installed, like in my case, then both these commands would work without any problem. However, I prefer to use switch. And then we're going to provide the hashCode of the combat where we want to devote to. Let me paste the code. You don't have to paste the entire code. The first few characters would actually suffice. Now, if I hit Enter, we're going to get a hint from get's saying, if you want to detach, head at the commit, try again with detach option. Well, whatever we're doing right now is actually called detached head state. You're going to understand about it in next chapter and get this also saying a branch is expected. But it got commit. Like I said before, whatever we're doing right now is not actually the recommended approach. The recommended approach is actually to use branches. Once again, we'll talk about it in next chapter. That's what Git is even recommending. It is expecting us to use branch and not a comet. Let's proceed by including the hyphen hyphen detach option. And if you notice the moment we run that command, you don't see three dot TXT file anymore. And even if you were to take a look at all the list of commits, by doing git log. It's going to print only two commits. Essentially. We just went back in time to bring back the project what it was when they made feature to commit. It's equivalent to, I have done no changes after I made feature to come at. How cool is that? You can actually go to the future as well. And I'm not wrong in saying that. Let me come up with the hashCode of feature three. This time. Let me run git checkout and Strauss, which then I'm going to specify the hash of the third commit, our feature tree commit. And take a look at what would happen inside our working directory. Well, you see three dx, dy again, we're back to the future. How cool is that? I wish there is something like this in our lives. I mean, I could just go back in time, fix things up, maybe invest in Bitcoin, and come back to the future. How cool would it be? It's only possible and get, at the moment. It's crazy, but at the same time, kind of spooky to be honest, but that's the power of good. But anyway, do try and experiment with this feature. Just play around with it. And don't bother about terminologies like head, branch, et cetera. We're going to talk about all that in next chapter. One more thing I should mention is that whenever we are switching or checking out another commit, Get was able to bring back the working directory back to what it was when we made that comment. And it has happened very quickly. The reason why it happens so quickly is because of the concept of snapshot we had discussed in one of our previous lectures. In other version control systems. What the story is actually the difference of files compared to their previous commits. And when we add the tool to bring back the project to a certain state, it's actually going to sum up all the differences to recreate the files to what they were when we made the commit. However, in case of get, it's all about Snapshot. Basically, each and every commit object points to a snapshot or the root tree object, which has all the information of all the files residing in our working directory and all its corresponding blob objects. So it's relatively faster. Forget to retrieve the content from Blob objects and almost instantly or quickly load all the files onto the working directory. That's the power of storing a snapshot compared to storing the differences are pad sets like we discussed in one of our previous lectures. It's like when you're playing a game, you're going back and forth between multiple sale points. Somewhat similar to that. Hope it makes sense. 23. 0301 Life without Branches: Let us see how his life before git branches existed. And you can tell by this image that it must be a very frustrating experience. Imagine that we have Bob who is an investment advisor and sender, who is a freelancer. Bob asunder to create an application for him. And sender has created one application and Bob is quite happy with how the application functions. And now Bob has decided to add a few more features into his application. And sender has accepted to work on those features. Now assume that sender has started walking on feature one and committed all those changes and has shown it to Bob. Bob is quite happy with how the feature one is functioning. And he has given green signal to continue working on other features. So sender has continued working on feature to as well. And sent an email to Bob asking him to verify the feature. But this time Bob is quite busy with this clients. And so he hadn't got any time to check this feature. However, some there has decided to continue working on other features because if he keeps waiting for Bob's reply, he might not be able to meet the project deadline. So he delivered feature three and feature for as well, and has sent an email to Bob asking him to verify all these features. Bob verified all the features. And for some reason Bob is not happy with feature to end that he has decided to eliminate that feature altogether from his application. So cinder thought about it a bit and he realized that it's really difficult to undo all those changes. Because if he tries to undo all these changes, he might end up breaking some of the features which were walking. Another thing that's on the thought of doing is to go back to one of the previous versions of the project by running the command gets which are git checkout. But the problem with that is Cinder will not only get rid off feature to changes, but he will also get rid of feature three and feature for changes which are working fine. And Bob is quite happy with these features. This is just the tip of the iceberg as to the kind of problems we might face when we don't use branches. For example, in real-world applications, you might not be the only person who will be working on the application. You might have the code base and the list of commit histories, deciding on a centralized repository and multiple team members and could be from multiple teams, would be contributing to that project. Everybody would make their own commits, introducing their own features. Now we cannot risk going back to one of the previous versions and risk losing all the team's effort. Another problem you might face without branches is when you want to work on multiple features simultaneously. Let me explain you what I mean. Assume that you are assigned with all these features and you have to finish them before a deadline. Let's call them feature F1, F2, F3, and F4. While it's not recommended that you multitask, sometimes use situation might demand you to work on multiple things simultaneously. For example, assume that you started working on feature F and made some changes related to F1 inside your working directory. And then you have to write an email to somebody. And based on what the reply, you'd want to continue with feature one. While you wait for the reply. You're not expected to watch YouTube or something. Your boss would expect you to take up another task. Maybe start working on feature to, for instance, you pick up feature two and start working on it. Introduce code related to feature two. And then let's say that you're dependent on somebody else for feature to as well. And you have to wait for the reply. So you take up feature three as well. While you're managing all these features, waiting for replies, and updating the code accordingly. Your boss would ask you to send an update on feature for you. We'll tell you about it is in progress even though you haven't started on feature for just to keep them happy, you might tell him it is in progress. So you're kind of forced to start working on feature for now. And then suddenly you get to reply for feature one. Or someone in your team ask you to deliver feature three because they are dependent on them. I hope you're getting where this is leading to. When you have all these partial changes of all the features inside your project. This would lead to a lot of mess and a lot of frustration. Let's talk about one more realistic problem that you might face if you don't use branches. Imagine that you have centralized repository where all the team members would be contributing to the code base. And there comes this new lady who just joined the team. She didn't have any experience in programming. She just graduated out of college and join the organization. And she was assigned with a feature to work on. While she's working on the feature, she felt like there are too many changes to come back. So she thought of making a partial commit onto the code base. So she commits those changes. And obviously, as you can expect, this is not an ideal thing to do. But she is new to the team. She doesn't know a lot of things. She's still learning and she made a partial commit. And rest of the team members would start taking those new changes because they need to get the latest code to start working on their own features on top of the existing code. And they contribute to the project, introducing their own set of changes and introducing new features or bug fixes. Now because of that partial commit done by this young lady, all the future commits might actually break as well. Or even worse, it might actually break things mature, working fine earlier. Now it's understandable that she is new to the team and she's bound to make mistakes, but harbored all the senior members in the team who did a fair job. But yet they have to take the blame because their code is not working as expected due to the changes introduced by this young lady. Now this is just a consequence of mistake done by one team member. How about multiple team members introducing all those half cooked ideas onto the main code base. It will soon become a nightmare. It will soon become hard to manage, not being able to meet the project deadlines, too many issues to fix, et cetera. So I guess I now need to learn about git branches. Absolutely. Then what are you waiting for? Each meet those stuff damaged. Okay. Easy cylinder. That's the plan. That's why I'm here. I'm here to teach you. Thanks. Thanks. You're welcome. 24. 0302 What are Git Branches: Okay, let us try to get some idea as to what our git branches. Now I do have to mention that with this video alone, you may not be able to understand or get complete picture as to what git branches are. You need to watch all the rest of the lectures in this chapter in order to have a complete picture of what our git branches, what is the purpose, why they existed, and how they solve all the problems we had talked earlier. So let's move on and try to get as the staff, what I'll get branches. Git branches is such an important feature in git that even the logo itself is having a symbol representing get branches. So you can understand the significance of this feature in git. Now I want to ask you a question. What is the first thing that comes to your mind when you hear the word branch? Would you imagine something like this? Well, you're not wrong. Here. If you observe we have a main branch and then we also have sub branches which come from the main branch. And each one of these branches are having their own set of leaves. Well, this is synonymous to what branches are n get as well. So n get, you might have a master branch created by get when you initialize the project and make your first commit. We don't have to manually create this gate, has done that for us. And all the comments that we've done so far went inside this default branch, master branch, even though we're not aware of it. And then we could also have feature branches that come from the master branch. Just as we have main branch and sub-branches in a real-world branch, we also have master branch and feature branches in good. And just as each of the branches would have their own set of leaves, even in Git, we have convects residing in each one of these branches. And all these branches would evolve independently. For example, if you make a commit and feature one branch, those changes will not be available in any of the other branches. Same as the case with other branches. If you make a comment and master branch, then those changes will not be available in other branches. If you want to make a commit in a certain branch, you need to switch to that branch and make a commit in that branch. And those committed changes will not be available in other branches. And when you switch to a branch, git will make the working directory look like what it looked like when you made the last commit in that particular branch. Eventually, the goal of all this feature branches in most cases would be to get merged in the master branch. Which means we will now have all the changes introduced in this feature branches inside the master branch. Now, obviously, this may not be making complete sense to you at this point in time. So let's break it down and see how this project might have evolved from the beginning. So when initially as the project and make your first commit, you have a master branch created by good. And let's say that you have made a couple of comments. These comments would go inside the master branch. So we have the first commit which does not have any parent. And then you have the second commit, which has the first commit as its parent commit. And now let's say that you are assigned to work on feature one. Instead of committing all those feature one changes inside the master branch. What you're going to do is you're going to run a command to create a feature branch. And this would just create the feature branch. And once you do that, you need to switch to that branch to be able to make commits in that feature branch. So you would run a command to switch to that branch. And once you do that, you're going to start introducing all the feature one changes. When you make the first comment. We have a comment object whose parents would be the last commit of the branch from where you created this branch. In this case, it's the master branch. So the first comment that you made inside the feature one branch would now point to the last commit of the master branch. And then let's say that you have made couple of comments inside the feature branch. None of the changes that we've introduced in feature one branch would be available in master branch. Because as I've mentioned before, all these branches would evolve independent to each other. Now let's say that you have decided to work on something else and you wanted to contribute all those changes inside the master branch. So you would again switch to master branch and make a comment. Do take a note that these two commits or having the exact same parent and whatever the changes that you've introduced with this new commit inside the master branch will not be available inside the feature branch. Feature one branch would only have all the changes introduced in master branch till the time you created feature on branch and made the first commit. Plus all the changes that you've introduced in feature one. Okay, Let's say that you have made one more comment inside the master branch. And it is at this point in time, let's say that you are asked to work on feature to guess what you're going to create yet another branch, let's call it feature to branch. And then you have to switch to that branch to be able to make commits inside the feature to branch, you're going to make a commit. And this time it would be trapped inside feature to branch. And this commit object would be pointing to the last commit up the master branch, because it is the master branch from where we have created this feature to branch. And all the subsequent commits you're going to make would be tracked inside feature to branch. Now once again, you might want to go back to master branch and make bunch of comments and not dimension feature to branch will have changes that you've introduced in master branch till the time you created feature to branch and made the first commit. And all the comments that you've introduced in feature to branch, but does not have any of the changes that you've introduced in any of the other branches. Like for example, feature one branch. Eventually you want to merge all the changes that you've introduced in this feature branches into the master branch so that you have all the changes inside the master branch. Now, obviously, you might be having a lot of questions as to how this would solve all the problems we had talked earlier. And what exactly is branch? How does it work internally? And how is it managed to what it means to when you switch to a different branch, you, and to find answers to all such questions in next few lectures. And by the way, I've mentioned that we make commits inside the master branch. Typically we do not tend to make commits directly inside the master branch. We always create a new branch, beta feature or a bug fix. And then once we are sure of all the changes, once we test them, get them reviewed, only then will we merge all those changes inside the master branch. So essentially what master branch would have is so-called a merge commit. Will talk about merge commits in upcoming lectures. I don't want to talk about it right now and confuse you further. I'll see you in the next one. 25. 0303 How Branches Solved our Problems: Okay, so far we have some idea about branches. Now let's take a look at how branches solve the problems that we had talked earlier. Let's talk about them one-by-one. Imagine that you are asked to work on multiple features simultaneously. This time, you're going to have multiple branches, each corresponding to individual feature. It's very easy for you to multitask because let's say that you wanted to work on feature one. You just simply going to switch to that branch and continue working on feature one. Somewhere in the middle of your work, you might have decided to work on another feature, say feature to maybe because you're waiting for an email reply or whatsoever. So guess what? He went to switch to a feature to branch and continue working on feature two. And since coat changes introduced in one branch will not have any impact on the other branches. There's no chance that you would confuse yourself with code changes introduced for multiple features. We have a separate contexts for each and every feature. And they evolve independent to each other. So branches has sort of solve the problem of not being able to multitask between multiple features. Now assume that some inexperienced programmer joined the team. Guess what? They can just create a branch, experiment. Everything that they wanted to experiment, make mistakes, learn from those mistakes, and bring updates. Finally, when they're ready with the changes. And once after the test all those changes, senior members in the team can actually review all the code changes. And only then will they accept all those changes to be merged with the mainstream of development. So there's no scope of one member in the team messing with the code and costing other's work as well. Now let's say that you wanted to get rid of one of the features, then you don't have to take their forte of undoing all the changes and risk creating problems. Or you don't have to go back to one of the previous commits and risk losing all the team's effort that came after it. Instead, you can just simply delete the branch and you get it up. The feature that you don't want. It will not have any kind of impact or influence on others work. One another advantage with branches is that you can make partial commits. Without branches that we made partial commits, you might risk introducing new bugs in your application are breaking some of the working features. However, with branches, you can make multiple partial commits, especially if your feature is very big. And once you're done, you're just simply going to merge all those changes onto the master branch. Hope it makes sense. 26. 0304 How Git Branches Work and What Exactly is a Branch: Okay, Let us try and understand how branches would work. But before that, let us understand what exactly is a branch. If I were to define a branch, a branch would simply be a reference to a commit, or in other words, is just a pointer to a specific commit. Now you might be wondering how come something as simple as this can do so much for us? It does. Let me explain you what I mean. Let's set that up. Just initialize the project using git init command. And since branch is a reference to a particular commit, we need at least one commit to have a branch. And that's why you're not seeing anything right now. A branch would be created the first time we make a commit. And that branch is the master branch, which would be created by Git itself. We don't have to do that manually. You can think of it as simply a file with the name Master, whose content is going to be the hashCode of a specific commit. And a branch always points to the last commit on that branch. Currently we just have one single commit. This master branch would point to that commit. Now let's say I made a new commit, then the branch would now point to that new commit, so on and so forth. And make a new commit and branch would point to that new commit. Now let's say that I have to walk on feature one. We're going to run a command to create another branch. Let's call it feature one branch. The moment you run that command, git will create a new branch, essentially a new file with the name feature one, whose content would be the hashCode of a specific commit. What would it be? Can you make a guess? Well, it would be last commit off the branch from where we have created feature one branch. So it would point to this commit. Now let's say that I've made couple of more commits. Where do you think those comments would go into Mel? It would go into master because this is the current active branch. So those two comments would go inside the master branch. And as you can guess, master would now point to that very recent commit in that particular branch. Now let's say that you wanted to make some comments inside feature branch. Well, you have to run a command to switch to that branch. And once you do that, all the commits you're going to make will be tracked inside the feature one branch. If I make a commit now, how do you think the diagram would look like? Well, a branch would always point to the last comment on that branch. Feature. One branch would now point to this new commit. And this new commit will have the master branch commit as its parent. So it is at this time we will have two commits having the exact same parent. Now let's say that I made a couple of more comments. Where do you think those comments would be tracked? Well, since feature one branch is the current actor Branch, those comments would be going inside the feature one branch. And of course, feature one branch would now point to the last commit on that branch. Now, my question to you, imagine that I've added one file in each one of these comments. Now, if I were to look at the working directory, what are all the files you're going to see? Can you guess? Well, every time you switch to a branch, git will rewrite the working directory to look like what it looked like when you made the most recent commit on that branch that you've just switched to. So in this case, the current actor branches feature one batch. So you're going to see all these files a, B, C, and F, G, H. You're not going to see files D and E. And now if you were to switch to master branch, you're going to see a, B, C, D, E files, but not F, G, H Files. Hope it makes sense. I'll see you in next one. 27. 0305 Branches in Action (Creating Branches and exploring the git repo): Okay, Let us see branches in action with a quick example. Once again, I'll create a new folder, my app, and this is where we're going to experiment everything about branches. I'm going to launch Git Bash here. Let me create one file committed on the master branch. And we're going to start from there. I'm going to get initialized the project. And then touch one dot TXT to create that file. Git add one dot TXT to stay as that file. And before I commit the changes, let me take you to get refs, heads directory. This is where it would create list often branches. Let me go back to Git Bash and let me comment this change. Git commit hyphen m. First commit in the master branch. The moment I commit these changes, you're going to see a new file being created by gaped. Let's take a look at what's inside this file. To take note of the name of the file is the name of the branch, the default branch that God has created for us. It's master. And the hashCode is the hashCode of the commit that we've just done. If I go back to Git Bash and do git log, the hashCode that you see here is exactly the hashCode that you see inside the master file. So essentially the branch master is pointing to this particular comet at the moment. Let's make one more comment and see what's going to happen. Touch two dot TXT file, git, add two dot TXT. And then once again, let us commit the change. Let's call it second commit and master branch. And let's take a look at the content inside the master file. So cat dot get refs heads and then the file master. And as you can see, Master is now pointing to the last commit in this current branch. So if I do git log, you're going to see that the master branch is actually pointing to the very recent commit that we've done. Now let's try to create a new branch. And the command for that is git branch. And then you're going to specify the name of the branch that you want to create. Let's call it feature one. So this has created feature one branch, but we're still on master branch. And you can tell it by looking here, it says Master, so we're currently in master branch. If I make a commit right now, that come it will not be available. Feature one branch. But if you notice, it has also created another file inside the heads directory with the name feature one and gets the content inside it. Well, it will be the hashCode of the last commit off branch from where we created feature one branch. So essentially if you take a look at the content of feature one file, it's going to point to the last commit of the master branch. As expected. Now if I make a new commit where you think the changes would go into, it would be inside the master branch because that's the current act to branch. So let me make a commit. Dutch three dot dxdy, git add three dot dxdy. And we're going to make a third commit inside master branch. If I do ls, you're going to see all those three files. But if I switch to feature one branch, so I do get switch and the name of the branch I want to switch to. Feature one. You can also use the command git checkout and the name of the branch head away. As you can see, we have switched to feature one branch. You can also tell it by looking here. Now, can you guess what are all the files will be seeing if I do ls? Well, we should only be able to see one dot dx dy and dx dy. And not freed up dxdy because three dot text is created and master branch, after we created this feature branch. As you can see, we're only seeing one dot d x into rho TXT files, which is expected. Now since we're inside the feature one branch, all the comments I'm going to make now would be trapped inside feature one branch. Let's do one comment. I want to create one file, touch. Let's call it, which are 13 dot TXT file naming like this, just so that we know that this belongs to feature one branch. For the time being. Git add. We're going to stay as that file, git commit m, adding feature 13 file in which a one branch, whatever. So we made the comment if I do ls now, you want to see all these files. Let me go back. The working directory. You're going to see all these files. Well, let's take a look at what would happen if I were to switch to master branch. So I use gets which command. Or I could also use git checkout and then the name of the branch. The moment I do that you can see it has updated the working directory that suits master branch. So get is aware of the snapshot of the latest commit diamond master branch. And it's going to make the working directory looked like how it looked like when we made the last commit in master branch. And if I were to switch back to feature branch, once again, you're going to see the working directory getting updated accordingly. We don't see three dot, dxdy. And feature branch would now point to the last commit done in that branch. So if you do take a look at the content of feature one branch, the hashCode is now updated, pointing to the latest commit in future one branch. If you do git log, you would see that that is the latest commit done in that branch. Now it's really crucial for you to understand how exactly is this working. I want you to experiment with this. Create files on multiple branches, switch between multiple branches and try to understand how good behaves with branches. If you do not practice, it's almost certain that you will confuse yourself pretty soon. So do not hesitate to practice. You feel like you're knowing everything, but when you actually practice, you might have surprises. So don't hesitate to experiment with this. Take some time and practice what I've just taught and make sure that you're comfortable with branches. 28. 0306 Understanding 'HEAD' Detached Head State Head in Action: Let us understand what is ahead and get. My branch is a reference to a commit, head-related the point to a branch or to a specific commit. When the head points to a specific commit, it's called detached head state. Let me explain you what I mean. When you have a project with no other branches except the master branch, by default, head would point to the master branch. Now assume that you have two branches, master and feature one branch. Let's say that you have switched to feature one branch. The head would now point to feature one branch. And based on the head, get will know which branch it needs to commit the changes to. If the head is pointing to master branch, git will make the comments inside the master branch, or the head is pointing to some other branch like feature one branch. Git will make commits inside the feature one branch. You can also have the head pointing to a specific commit. And we had already taken a look at an example of the same in one of our previous lectures. For example, you could say git checkout or good switch. And then you're going to specify the hashCode of a particular commit to objects. The head would then point to that particular commit and get will update the project working directory to look like how it looked like when you made that particular commit. And what are the comments that you make during the detached head state? All those comments would be lost once you switch back to one of the branches. So you might be wondering why is allowing us to checkout or switched to a particular commit. Well, there might be use cases where you might want to go back to previous state of the project. For example, let's say that you'd like to take a look at how our project look like when you made a particular commit on, Let's say that you'd like to retrieve some of the changes that were deleted earlier in one of the previous comments. Well, you can check out the particular commit. You take a look at all the changes, maybe copy the code that was deleted, and use that code in your current project. Once after you switch back to the branch or another use case of detached head state would be, let's say you want to go back in time and make few experimental commits. But you don't want all those commits to be available in your code base. And once after you're done, you would just switch back to one of the branches and all those experimental commits would be lost. Now let's take a look at all this in action. Okay, We are currently inside the feature one branch. First of all, let us try to locate where the head is actually residing. Inside the git folder. You're going to find this file with the name head. Since we are now in feature one branch, head is pointing to feature one branch. Let's see what's going to happen. If we switch to master branch. Let's take a look at the content of the head file dot get. And as you can see, head is now pointing to master branch. Now let's take a look at list of commits in this master branch, git log. And as you can see, we currently have three commits. And you can also see here that the head is pointing to the master branch. If you were to switch to feature one branch, let's say. And do git log for instance. You're going to see that the head is pointing to feature one branch. If you'd like to take a look at all the list of branches available, it is going to say git branch. And then you're going to see all the list of branches. And since the current branch or the ACT to branch or so-called the head branch is a feature one branch, it is highlighted in green. We also see a star mark giving us a clue that this is the actual branch or the current branch. So if I do git log, you can see that we currently have three commits. We've already taken a look at how we can check out or switch to one of the previous comments in one of our previous lectures. So I'm not going to do that. I would instead use a different command called Git checkout. Or you could also use good switch. Let's use that because it is the latest one. And then you're going to say head all caps. And then you're going to use this symbol, whatever it is. And then you're going to specify the number of commits that you'd like to go back to. Say if I say one here, then we can see the depository or the working directory, how it looked like one commit ago. Let me run this command. And this time if I do git log, okay, this command basically didn't work. It is asking us to add this option detach. So let's quickly do that. Now let's do git log. And you're only going to see a couple of comments. Now currently we are in detached head state. So let me try and make a comment here. Touch maybe Apple dot dx, dy. And then git, add apple dot TXT. Get come at, hyphen them. Some message. It doesn't matter. If I do git log. You would certainly see that commit. But once I switch back to one of the branches, you would no longer see this commit. This commit would be lost. So I'll do git checkout. Or you could also say, Good Switch feature one, git log. And you would no longer see the comment that we've just made. 29. 0307 Undo the changes with Git Reset HEAD: Okay, let us see how we can undo our changes are reverse the comments that we've done. In order to save you time. I've actually created a brand new folder or brand new project. And we basically have these three files. Each one of these files were committed in their own comments. For example, if I do git log, you see that we have three commits. In the first comment, I have committed one dot TXT file. In the second comment I committed to dot TXT file and enter commit. We have committed three dot TXT file. This is just to save your time. We've been creating projects and creating files and adding them to staging area and committing those changes for awhile. I hope that I don't have to walk you through this again and again. We don't have any other branches at the moment. We have the default master branch. Let's take a look at how we can do also changes our undo bunch of commits. And also we're going to talk about couple of more comments which I find relevant to talk about right now. So let's say that I've accidentally committed these changes and I wanted to undo those changes. Now there are three options for me. I can just undo this commit, but keep the files in the working directory. That's option one. Option two is I can undo this commit, keep the changes in working directory, and also have those files staged. And then the third option, I undo this commit as well as I delete all the changes that were done in this comment. So let me demonstrate all such scenarios. And the command for that is git reset. And I'm going to say head. What are the symbol is? I don't know what the symbol is. I guess it's called Tilda. If I'm not wrong, I hope I'm right. And then I'm going to give a number here. If I specify two here, I would like to undo to comments. Let's try with one commit. I hit Enter. So what this has done is this has undone the last commit. But we still have the files inside the working directory, but not in staging area. So if I do git log now, you're only going to see first, second commit. But if I do ls, you're going to see three dot TXT file. Because as I've mentioned before, we still have the changes in the working directory. If I do git status now, you see that this file is not staged. So we can introduce all the changes we wanted to introduce. Make all the updates. As soon that I've done some changes in three dot TXT file that I now wanted to commit. So I may call those changes as soon that I've done those changes, I'll git add dot txt file again. And then I'll redo the commit git log. Now, you see that we have all those three comments. Now let's see what would happen if I run this command with soft option, this for Lambda, this combat. But we still have the files inside the working directory as well as on the staging area. I run this command. Git log. You see only two commits. And if you do ls, you're going to see all three files. If you do git status, you'll also see that those changes are staged. So I can just commit those changes. I'm going to make that comment. And life is back to normal. Now let's say that I've committed a terrible blunder. And I just would like to not only undo those changes are under the commit, but I also would like to get rid of all the changes I've done in that comment. Well, the option for that is you need to use git reset head tilda, number of comments that you'd like to go back to. And then you're going to use the option hard. Now if you do git log, you would obviously see two commits. But if you do ls now, you're only going to see two files. It is as though I have never done the third comment at all. 30. 0308 Retrieving the lost mystery with reflog: Now let's assume that you've changed your mind. You feel like you have accidentally undone the comeback and you'd like to retrieve all those changes. Well, there's a way for that. Fortunately, get, we'll keep this commit objects and its repository for a good period of time before it decides to delete them. When it does the garbage collection and all. So let's take a look at if we can retrieve all those changes. First of all, we need to get hold of the hashCode of the commit. Those changes would like to retrieve. So how do we know the commit ID? Right now we can just scroll up and get the commit ID. But you may not be able to scroll up every time. For example, if I close this window and reopen, it's gone. So how do we get hauled off the commit ID? Well, get offers a command that will help us out for just that command is log, our reference log. Whenever we updated our friends in the local repository. But running a command, reference logs have a record of that. And you can see all those records by running this command. Here, you can get hold of the hashCode of that commit. Well now I could just add git checkout and go to that commit. And that would bring us to a detached head state. However, you can just copy all those changes, bring all those changes, and make a new commit. But we have a better way to deal with that. So instead of doing git checkout and then specifying the hashCode of that commit. What we're going to do is I'm going to specify the option hyphen b, and I'm going to specify a name. And this name is essentially going to be name of the branch that we're about to create. For example, let's say new branch. By the way, for branch names, we would never use whitespaces. We would want to use hyphen instead. So what this command does is when we have this option hyphen b, this will not only create this particular branch, but we'll also switch to that branch. And it's going to point to this comment. Let's run this command. And as you can see, we have switched to that new branch that we've just created. And if I do git log now, you can see that we have the third and the other two comments are actually from the master branch and escalate the branch from where we created this branch. But how do we get the commit three changes into our master branch? Well, we can do that with emerge. We haven't talked about mergers. We will talk about it in upcoming lectures. But maybe I'll just quickly demonstrate to you, just to give you a sense of what is a merge. So for that, I'd like to switch back to master branch. I'm going to use the command git, merge out, specify the branch I would like to merge into master branch. In this case it's new branch. Now if I do git log inside the master branch, you're going to see we have those new changes. What we've done just now is so-called a fast forward merge. Again, we're going to talk about more just in coming lectures. Don't think about it too much. One last thing I'd like to mention is that when you reverse the changes or reverse a commit. But if you've already pushed those changes onto the remote repository, then it's going to create a problem. Now since we haven't talked about centralized repository and team collaboration, I'm not going to talk about the Seder, but as a rule of thumb, just remember, if you'd like to undo the Commit, do it before you actually push all those changes on to the remote repository. 31. 0401 Fast Forward Merge: The goal of having a feature or a bug fixed branch is to eventually merge all those changes inside the mainstream of evolution, which would typically be the master branch. In this video, let's talk about what is fast forward merge. Imagine that you have a project with master branch and with these three comments. And it is at this point in time, I have decided to work on feature one. And so I have created a feature one branch and I've also made a bunch of commits in it. Now let's say that we don't have any other additional comments in master branch. Once after I have created the feature branch, Let's say that I'm done with all the work I have to do inside the feature one branch. I have tested all those changes. And I now want to have all the feature one branch changes inside the master branch. Or in other words, I want to merge feature one branch into the master branch. Now a question to you, what can I do in here so that master branch, we'll have all the changes of feature one branch. Pause the video and try to figure it out. Well, let me give you a clue. I'm going to rewrite this diagram from this to this. I've done nothing. I just lifted the feature one branch but upwards. But this should give you some clue as to what we can do to have all the changes of feature one inside the master branch. Give it a try. Well, I'll give you another clue. We're calling this a fast forward merge for the reason. What's the FastForward part in that? Well, how about we asked Master to point to the latest commit or feature one branch. Wouldn't it solve the problem? Essentially, master branch has passed forwarded to bunch of comets. Master branch is now pointing to a commit which has a snapshot that is pointing to all the changes of master branch plus all the changes in feature one branch. And since we're done with feature one branch and I've merged all those changes inside the master branch. We can go ahead and delete this branch altogether. Now fast forward merge would only work if you do not make any comments inside the master branch after creating the feature branch. Now, another question to you. We've just seen how we can merge all the changes of feature one branch into master branch using fast-forward merge. Now would it make sense to say that I wanted to merge all the changes of master branch into the feature one branch. It doesn't make sense because feature one branch is already having all the commits are all the changes of master branch. However, if you've made any comments in master branch after you created the feature branch, that's a different story altogether. And we're going to talk about it in coming lectures. In the next video though, we're going to take a look at all this inaction. See you in the next one. 32. 0402 Fast Forward Merge In Action: In order to explain fast-forward Merge, I've brought the project into this state. We have the master branch with these three files, ABC, and there are delivered in three different commits. Similarly, we have feature one branch with the files D, E, F, and they're all delivered in three different comments as well. Now let's take a look at fast-forward much inaction. On the left we have the Git Bash. On the right, we have the working directory. You can simultaneously observe what is happening in working directory while we run commands on the Git Bash. So currently I'm in master branch and so you're seeing ABC files. If I were to switch to feature branch, then you're going to see the working directory would get populated with all the files, which includes changes of master branch as well as the feature branch. Now let's take a look at which commits out this brand just pointing to. I'm going to do git refs, heads master. And similarly, let's take a look at what the feature branches wanting to. And if I do git log, you can see that the feature branch is pointing to the very latest commit, but master branch is pointing to its latest commit in the master branch, which would be this. Now I cannot merge master branch into the feature branch because feature branches already having all the changes of master branch, it doesn't make sense. So we need to switch back to master branch. And then they'll get that we want to bring in all the changes of feature branch into the master branch. And once I run that command, we should be able to see the master branch pointing to this commit. So it gets the command git merge name of the branch that you want to merge. In this case it's feature one branch. And as you can see, the summary shows that these are all the files which are now part of the master branch. And even the working directory is updated with all of those files. If you take a look at what master branch is pointing to, then it points to the exact commit. That feature branch is pointing. That's fast-forward much for you. Now we can go ahead and delete the feature branch, but we're going to talk about it in next lecture. One thing I would like to mention is that you may not want to always delete the branch once you're done with it. Sometimes you might want to keep it for a while because there might be instances where you might need to make those last minute changes. Or there might be certain fixes that you want to deliver as part of the same branch. So you're going to use the same feature branch again to make all those changes, test them, get them reviewed, and then eventually merge all those changes in the master branch. And yes, you can reuse the same branch and you can merge the same branch again and again. However, most often we create another branch for bug fixes or any of those last minute changes and then merge those changes in the master branch. One another thing I would like to mention is that typically happens on GitHub in a centralized upholstery. Since we haven't explored GitHub, it doesn't make sense for me to talk about it right now. But nonetheless, merging is also the London local depository in certain instances. I'll see you next one. 33. 0403 Deleting the branch and recovering: Let us see how we can delete a branch in order to explain this. Once again, brought the project back to this state. I'm currently inside the picture one branch. If I tried to delete the branch when I'm actually in it, then it will throw an error saying that you cannot delete a jet dot branch. Let me try doing that. So the command that I need to use to delete the branches, git branch. And then I'm going to use the option hyphen D, make sure that it is lowercase d. And then I'm going to specify the name of the branch. We're going to see an error and it says cannot delete branch feature one checked out at so-and-so folder. I'm going to switch back to master branch to be able to delete feature one branch. If I try to delete now, get to is actually going to give us a warning that none of the changes in feature one branch, what actually most in any other branches. And as you can see it as saying, the branch feature one is not fully merged. But how does it know that this branch is not merged? It will take a look at the last commit of feature one branch. And it notices that there is no other branch pointing to that commit. Get gives us a warning. In addition to that, it is also suggesting us if we still want to delete that branch, then we can go ahead and do that with hyphen d option. This is uppercase D compared to lowercase D, which we had used earlier. And get has actually provided us default command. I can just paste it over here. And this would delete the branch. And of course we'll lose all the changes introduced in feature one branch. When we deleted this branch, git has actually provided us the hashCode of the last commit just in case if we want to do something with it. Now let us assume that I have done a mistake in deleting this branch and I wanted to retrieve it back. What is a command that will help me retrieve this branch? Once again, you're already familiar with that. We had used it in one of our previous lectures. Well, it's git, checkout hyphen b. And then you're going to specify a branch name. We can give any name of our choice. But I'm going to do the same name, pizza one. Then we're going to specify the hashCode of the combat that you want this branch to be pointing to. Essentially what this command is doing is it is not only creating the branch feature one, but we'll also switch to that branch with the last commit being this commit with this hashCode feature, one branch would be created, and that branch would be pointing to this commit that we've just deleted. If you run this command after a very long time, after deleting the branch, you may not be able to see this commit anymore and you would actually lose the data. So let's retrieve that branch once again. And as you can see, we have switched to that new branch. And if you do git log, you can see that the branch is pointing to the exact same commit. Actually the right way to look at it has taken a look at what's inside feature one branch file. And as expected, it is pointing to this commit. Now we can go ahead and merge all the changes by switching back to master branch. And that is something we've already seen in our previous lecture. Git, merge feature one. And this walks. You can now go ahead and delete this branch with lowercase d option and there's no problem whatsoever. Let's take a look at list off branches. And you'll see the only branch we have is now Master. 34. 0404 Understanding Three Way Merge and Merge Commit: Let us talk about three-way merge and get. Let's say that this is the current state of our project. We have the master branch with three commits, m1, m2, and m3. And then we also have the feature branch with the commits F1, F2, and F3. And imagine that in each one of these commits, we delivered one single file. For example, in M1 commit, we deliver m1 dot TXT. In M2 commit, we deliver m2 dot TXT, so on and so forth for all the rest of the comments. Now I'm not going to keep the file names in this diagram just to keep it clean. Now let us assume that while I'm working on feature one changes, I have two additional comments and master branch. Now a question to you, if I decide to merge feature one into master now, can we expect to perform fast forward merge in this case? The answer is no, it will not be able to do that. Okay, let us hypothetically assume that good has done fast forward merge. So we now have the master branch pointing to the latest commit off feature one branch. Can you guess what's going to happen? Well, we wanted to lose changes introduced and m four and m phi combatants because they don't fall under the parent hierarchy of the commit that the master branch is pointing to. This is not an ideal thing to do and the good doesn't perform fast forward merge in this case. What IT performance though is so-called a three-way merge. So what essentially does is when we decide to merge feature one into master branch, we went to go inside the master branch and ask get to perform the merge. And when we tell it so get will artificially create a commit with what we initiating it. This commit will have two parents. In other words, this commit object would point to two other common objects and those comments out the last comments of both these branches, this commit is called merge commit. And the resulting snapshot of this commit, the combination of changes introduced in both the branches. Essentially, if you want to view the working directory of master branch after performing the merge, you're going to see all the changes introduced in both the branches. Once we're done with the merging, we can go ahead and delete the feature one branch. Do take a note deleting feature one branch would only delete that branch, but not the commits that are in the feature branch. Because merge commit is referencing to commit. So feature branch, so get will not be able to delete that, are qualified them for garbage collection. Now what we are talking right now is the best-case scenario. Most often we have so-called merge conflicts. For example, if I added the same file in both the branches. And then when we tried to merge these branches, get is going to tell us that there is conflict of changes in both the branches only after we resolve that merge conflict. Well, the git merge all branches. Going to talk about merge conflicts in coming lectures. And you might be wondering why this is called a three-way merge. Well, you're going to find answer to that as well in upcoming lectures. Once after we talk about the merge conflicts. Next, we're going to take a look at an example of three-way merge, assuming that we do not have any kind of conflicts. I'll see you in the next one. 35. 0405Three Way Merge in Action: In order to explain driven much abroad the project into this state. I initially committed M1, M2, M3 in master branch, and then I've created the feature branch switch to it and made three comments over there as well. F1, F2, and F3. Once again switched back to master and I made additional commits, M4, M5. And that is the current state of our project. And not to mention, for each and every commit, I've committed their specific files. Now let's see how much is done. Currently I'm inside master. And so you're able to see all those five files corresponding to all those five commits. If I were to switch to feature one branch, you're going to see M1, M2, M3, and F1, F2 and F3, but not m four and m phi, which came in master branch after we created feature one branch. And this is the reason why we cannot perform fast forward merge. Now let's switch back master branch and perform the merge and see what's going to happen. Git merge feature one. And we have to do it from inside the master branch because we want to bring in all the feature one changes into the master branch. And when I run this command, it has actually opened the default text editor that I've chosen while installing the good. In my case, it's Notepad Plus, Plus. In your case, it might be something else depending on what you've chosen while installing Git. And what it is asking us is to enter some kind of a message. This is the message that would be associated with the merge commit. I can change the text to something else into master, something of that sort. Save the file and close the window. And this has created the merge commit. Alternatively, while running this command, I can also provide the option hyphen m and provide the message. That way get will not open the text editor. Okay, now let's take a look at get log n z. If God has created a merge commit. And sure enough, it did create the merge commit. And it has also mentioned that this committee is based on these two commits. These are nothing but the last comets of both the branches. So we have this hashCode from the master branch, and this belongs to the feature branch. Let's take a look at what's inside this merge commit object. So I'm going to copy it. I'm going to press Q to revert to the command line so that I can type in some commands. Git cat file, hyphen b, and hashCode of the merge commit. And if you notice it is pointing to these two commits. One is the last commit, the master branch, which would be this. And this is the last of the feature branch. Let's take a look at what's inside this tree object. I'm going to use the exact same command. And let's see what's inside that tree object. And let me expand. This tree object is actually combination of all the changes done in both the branches. So you see all these files, F1 dot TXT, after dxdy, F three, M1, M2, M3, M4, and M5. And even in working directory, you're going to now see all the changes of feature branch. If you switch back to feature branch, however, you would notice that there are no changes done in here. It's the exact same working directory as before, the mortgage. Now we can actually go ahead and delete the feature one branch. But first of all, let us switch back to master branch because we cannot delete the branch that we're currently on. So I'm going to use the get command. I'm going to say git branch hyphen D, feature one. And this has deleted the branch. 36. 0406 Understanding Merge Conflicts: Let's talk about merge conflicts and assume that I've made one commit in master branch, Let's call it M1. And as part of this comment, I have introduced the file product dot TXT with couple of lines of code. Now, obviously it doesn't make sense to write code and dot TXT file. You need to make an assumption that this is some kind of a source file, like Java file Python or whatever. Now I also should mention that we typically never tend to make commits in master branch. What we usually have in master branch, or so-called the merge commits, which we've discussed earlier. When we talk about centralized repository and team collaboration. You will understand how everybody would create their own branches to walk on their own features and then merge all those changes into the master branch in the centralized repository. And then when we locally update the project, we're going to get all those merge commits done by other team members into our master branch. If this sounds confusing, then you will have to hold on until we talk about centralized repository and team collaboration. For now, for the sake of this example, assume that we're making commits in the master branch. I made M1 commit, introducing this file product dot TXT with couple of lines of code. And then I made another commit, let's call it m2. This time I have updated the product dot TXT file with a couple of more lines of code. Let us assume now I have decided to work on another feature. Guess what? I'm going to create a feature branch, work on it, introduce all those changes. And then let's have made a commit wherein I have modified the product dot TXT file by writing couple of additional lines of code that are relevant to feature one. Meanwhile, I switched back to master branch. So our project file would look something like this because master branch is pointing to m to commit. And then let us assume that I made one more committed master branch updating the product dot TXT file, like you're seeing here. Now a question to you. Let us say I have decided to merge feature branch into the master branch. And I run the command and get to merge the branch. Would you expect get to perform the merge? The answer is no. Why? Because we have a couple of versions of product dot TXT file. In master branch we have product dot TXT that you're seeing on the left. And in the feature branch we have the file that you're seeing on the right. When we ask good to merge, it cannot keep both the files. Get this confused as to which of these changes it needs to keep or it needs to keep any changes at all. Obviously, it's not smart enough to make edits according to our needs. So it will leave it up to us to make all the changes, resolve the conflicts. Only then will get actually go ahead and perform the merge and create a merge commit. Essentially when you run the command to merge, it will throw an error saying that it has found complex in some of the files. And only after resolving them will it go ahead and merge the changes and create merge commit? Now why is this merge called a three-way merge? You might be wondering, well, it's basically because this merge involves three snapshots, the last two comments and the convect that is an immediate ancestor of both these comments. This colleague, it will compare the file in the immediate ancestor snapshot with the files in the latest snapshots in both these branches. Now if you didn't understand it, It's completely okay. It's not really worth knowing it. To explain it. Well, I have to actually go deep and again, get into those hashCode and all, which I don't want to because it's not at all what that just remember that this kind of model is called a three-way merge. And that should suffice. And fast-forward mode is also called as to emerge because it only involves couple of snapshots. Next, we're going to take a look at all this in action and see how we can resolve the conflicts. 37. 0407 Merge Conflicts in Action Part 1: Alright, let us take a look at merge conflicts, inaction. And for this purpose I have a new folder which currently has nothing. We're going to do everything from scratch. In this video, we'll try to create a scenario where we have conflicts. And then in the next video we'll actually see how we can resolve those conflicts to be able to merge the branches. First things first, let us get initialized the project. Now assume that I got a project from one of the clients, whereas asked to create a product management application. Inside the project, I might be having these files. We might have a product file which will have the product related source code. And then we might have an inventory file, and then maybe an admin file as well. Now, obviously these files cannot be dot TXT files. You need to make an assumption that these are some kind of a source file like Java, python, Node.JS or whatever. Now let's go ahead and populate something in this file, simulating that we're actually writing source code. Let's start with product dot txt file. Like so. You need to assume that this is actually some kind of source code. Save the file and close it. And I'm going to do the same for the other two files as well. Save the file and close it. Let's do the same for admin file. Save and close that. Let us stage all these files. Git add. I'll use wildcard character to stage all the files. And let's commit those changes. Whatever, some message. Now let us assume that I started working on another feature. And so I have to create another branch to work on all those features related changes. I'm going to use the command git checkout hyphen b, and then the name of the branch. So this command will create feature one branch as well as switch to it. So we are currently inside the feature one branch. Let us make some edits and these two files inventory as well as product dot txt file. But we're going to leave the admin dot TXT file as is. I'm just simply going to add a couple of more lines of code. But I'm going to say feature at the start of these lines, just so that we'll know that these lines are introduced in feature branch. You know the purpose of this in just a bit. I'm going to do the same for inventory dot txt file. Like so, save the file and close it. Let us stage all these changes. Some message and commit all the changes. Let me switch back to master once again. Let's clear the screen and let us try to update product dot TXT file. But leave these two file sizes. Obviously not going to see all those feature related changes here because we switched back to master branch. Let's close the file, stage these changes and commit those changes. Like so. So just to reiterate what we have done, we have all these three files hadn't been filed demand as is as it is before creating the branch. Inventory file is updated in feature branch, but not in master branch since that time we created the branch, but the product file has been modified in both the branches. Now can you make a guess which of these files will have conflicts? When we tried to merge, the changes will continue from next video. 38. 0408 Merge Conflicts in Action Part 2: All that. Let us try to perform the merge and see what would happen. I'm currently inside the master branch and when to run the command git merge feature one. Good says that it has spawned conflicts in product dot TXT file. And it says automatic merge failed, fix the conflicts, and then commit the result. That is pretty self-explanatory. In addition to that, gateway is also saying that our project is in merging state. In managing state. Git will format all those conflicting files in a manner that it becomes easier for us to understand the complex and resolve them. You will know what I mean in just a bit. But let's try to run the command git status and see what it has to say. It says that we have unmerged paths. And it is asking us to fix the complex and then run git commit command. What if we decide to get out of this merging state? We can run this command with dash, dash, I bought option, this will I bought the emerging state and bring back the project how it was before running the merge command. It has stage the inventory dot TXT file because it doesn't have any conflicts. It is ready to be merged. But whereas for product dot TXT file, it is categorized under unmerged paths. So all the files that are listed in this section, we'll need to resolve the conflicts and ask get to commit all those changes to complete the merge operation and create the merge commit. Now let's take a look at the contents of product dot TXT file. While our project is in merging state. I wanted to say cat product dot TXT file. And you can see that it is little bit different from how you might have expected. You would see the same even if you were to open the file in an external editor. What this essentially means is this section of code belongs to head, which means this call belongs to the branch where they had this pointing to. This is the changes introduced in the master branch essentially. Then we have these set of changes which were introduced in feature one branch. If you have bought the emerging state by saying git merge hyphen, hyphen bought. You would see that all that formatting is gone. And our project is essential in estate as if we had never run the merge command at all. Let us try to merge again and see how we can resolve these conflicts. Now as the programmer, you have to decide which one of these changes you'd like to keep. Or if you want to keep both these changes, you can go ahead and do that as well. You can literally do water we want to do. And once you're done, just ask get to commit those changes and create the Merge Objects. How to finish the merging of both the branches. So I need to get rid of this weird characters that has introduced. And then maybe I'd like to remove this line of code, but keep all these three. Just an example. What, oh, that makes sense. You'd like to keep that code. Save and close it. And once you resolve all those complex manually, you can go ahead and say git commit. Before we come in, we need to actually stage this file, product dot TXT file. And then we can go ahead and with the changes is asking us to enter a commit message. I'm happy with the default one. I wanted to save this file, close it. And this has successfully created a merge commit, which means our margin is now done. And so you would no longer see the status more gene. Let's now take a look at the content inside all these files. The admin dot TXT file would remain as is because it's never modified in either of the branches. Anyway. In inventory file, you're going to see all those feature changes added. And these were merged from the feature branch. Put in product dot txt file. It would have the code that we've updated while resolving the conflicts. Also, I hope that you're getting a sense of the need to have a more robust tool to manage your project and its files. And also be able to visualize all the historical changes, et cetera. And that's where tools like Visual Studio, Code, GitHub, Desktop, source tree, et cetera, would come into picture. We're going to explore them in coming lectures. 39. 0409 Installing and setting up Visual Studio Code to work on Git: Okay, it's time to install it to and use one of the tools available to help us manage our project in a better manner, because we cannot just keep on using Windows file system and Git Bash to work on our project. As a project gets more complex, we need some kind of a tool that will help us manage our project in a better manner and be able to view some of the historical changes or list of commits we had done. Take a look at list of branches while also being able to perform some of the operations without having to run commands in the Git Bash. So there are lots of tools available online and there's no single tool that is fit for all kind of thing. If you go to the official website of gate, which is Git SCM.com, python SCM.com. And if you go to this section grid lines, you're going to see that they've listed are recommending all these tools. If you use any of these tool, it shouldn't be hard for you to use any of the other tools available here. Because although they differ in terms of graphical user interface, they pretty much offered the same exact functionality. Github, desktop and source tree, or two of the most popular choices. But we're going to be using Visual Studio Code. The reason why I'm recommending this is because Visual Studio Code is one of the popular code editors. It is one of the popular choice as to develop JavaScript Python applications, and it has support for host of other programming languages. But what differentiates Visual Studio code from some of these tools are valuable here is that its ability to install extensions. And that's how we're going to install a good extension. And that will give you some of the features offered by some of these tools. These tools in here. Visual Studio Code is more of a holistic tool, rather than just aiming at get specifically. Once you're used to using Visual Studio Code, it should be very easy for you to understand some of these tools AND gates. If you want to choose one of these tools, then you can go ahead and do that if you're comfortable with that. But I'm going to be using Visual Studio Code with a quick Google search. We got to this page. Go ahead and download Visual Studio, depending on the operating system you're using. I've already done that. Let me launch the installer. Installing it is pretty straightforward. You can just leave everything to the defaults unless you want to change something. Okay, it's installed. Let's launch Visual Studio Code. First things first, let us go to the Explorer and when to open up the project by clicking on Open Folder. I'm going to choose my app that we had created earlier. In addition to that, I'm going to go to the section called extensions. I would search for Get. Get lens is one of the popular choices. Get graph is also a good choice. Let us install it. Alright, in the next video, we're going to see how we can handle merge conflicts in Visual Studio code. So that will give you some exposure to Visual Studio Code as well as mob the get operations we can perform on it. I'll see you next one. 40. 0410 Exploring VS Code and performing GIT Operations: Okay, Before we actually take a look at how to create merge conflicts and resolve them in Visual Studio code. Let me just walk you through the current state of our project. If you remember, we had merged our changes from feature one to master branch. These are all the list of files in our project. Can just click on them to take a look at their content. And if you go to this section source control, you can also go there by pressing Control Shift G. And since we had installed this extension good graph, you should be able to look at this icon. Here you can see all the historical changes we had introduced. You can also see the graphical representation of all the list of commits we had done, the branches we had created, and even the merging that we had performed earlier. This is the first commit we made in master branch, and then we create a feature branch. We made a comment there. And then we made a comment and master branch and eventually feature branches merged inside the master branch. To create the merge command. He didn't click one of these commits and take a look at the changes introduced in that particular commit by clicking on a particular file. And you can see the changes. Now let's go ahead and create conflicts which we, humans are naturally good at. Let's go back to Explorer. But before that, let's see how we can create a new branch. I'm going to create a new branch right here. So I'm going to right-click on this particular commit and say Create Branch. Let's call it feature to branch, whatever. And I also would like to switch to that branch. So I check this check box create branch. So we switched to that feature to branch that we've just created. You can tell it by taking a look here. Here you can see all the list of branches. Once you click on it, you can see all the list of branches. If you'd like to switch to one of the branches, just click on it. So we just wish to master branch. And so that's what you're seeing in here. Let me switch back to feature two branch and make a commit. I'll go to the Explorer. Let me just make some edits and inventory file feature to changes in inventory file or whatever. I'm going to go back to this section source control. I'm going to click on this check icon. By doing that. It is showing me a message saying there are no staged changes to come. It would you like to stage all the changes and commit them directly? If I hit yes, right now, it's going to stage the changes before committing without me having to do that. Or if you'd like to do it on your own, you can do that as well. Just right-click on this file which is currently under changes category. And then click on stage changes. This would move that file into staged changes category. And now if you come at, you shouldn't have any problem or whatsoever. But let us enter some kind of a commit message. Whatever. Click on this icon and just made a new commit and feature two branch. Let's take a look at the graph. And as you can see, we now have a new commit added in the graph. And here it is. Let's now switch back to master branch. Let us make edits in this same inventory file. So to create conflicts, save the file. Go back here. This time. Let's hit the S. If you don't like to see this prompt again, then you can just press never. Lets go back to get graph once again. And as you can see, we now have a new commit and master branch. Now let us try to perform the merge. How do we perform much in Visual Studio Code? But this extension, well, it's pretty easy. Just right-click on one of the branches. I'm going to click on feature to branch. And you can choose this option that says merge into current branch. What is the current branch ie mask? Well, it's simply the branch that had this pointing to. In other words, it's the master branch. Let's click on it and see what happens. It is asking us if we want to create a new commit, even if fast-forward merge is possible? I don't like to answer. Yes, merge. As expected, we have a conflict auto merging inventor or dxdy. And then it says we got a conflict. Dismiss it, go to Explorer, go to that file. And this time it has format at us in this manner, just as before. But we use today God gave us few options. If you notice, accept current changes, accept incoming changes, or the changes that are coming in from the feature to branch, to the master branch. Or accept both the changes. Or you can also compare the changes. You can choose. Any of these options are if you'd like to make your own edit, so you can do that as well. Simply just delete everything and bringing your own changes or edit the existing one. Whatever. Let's add like to keep both the changes or click on this that says accept what changes. Now save the file. Go back to source control. Before we commit it. Let us stage these changes are fairly staged. Let's click on this checkbox. I'm happy with the existing message. And guess what? This has just created the merge commit. Now, if you're using a different tool, not the Visual Studio Code, then you should be able to look at all these operations in some way or the other. Only the graphical user interface might change. But in all those tools, you can perform pretty much the same set of operations. For example, if you go to the official website of source tree, just by taking a look at this image, you can tell a lot. So we have history which shows the historical changes. You also have this graph, just as the one we have in the Visual Studio Code. You can also go to this branches section to take a look at the branches and do something with that, like create them, delete them, et cetera. You can also perform commits. And some of the other operations we haven't explored. We will explore in coming lectures for sure. But I hope you got the point. It doesn't matter which tool you use. Ultimately, every tool has the same purpose, which is to simplify your job. Now I guess we can delete this branch. We would no longer need it. So I'm going to right-click on this branch and say Delete branch. Can do the same feature, one branch as well. And of course, the leading brand doesn't delete it's commits. As we had discussed before. Hope it makes sense, right? To do what I've just done in Visual Studio Code and get a sense of how everything is functioning. And don't be intimidated by looking at this tool. It's pretty simple. Tool is just simply like a text editor with some really cool features. It's there to make our life easier, not harder. I'll see you next one. 41. 0411 Git Rebase vs Merge: Let's talk about git rebase. Git rebase is sort of like an alternative to merge. It serves pretty much the same purpose as with merge operation. But that being said, you cannot replace one with the other. We cannot replace VBS with the merge, and vice versa, we cannot replace merge with the rebase. It has its own pros and cons and each has its own purpose. And that's what we're going to talk about in this lecture and the next couple of lectures. First of all, let us try and understand what exactly is rebase. In case of three-way merge, GET request to create a merge commit whose snapshot would constitute the changes of both the branches. While this doesn't sound like a problem, we do start to see some problems with it, especially when our project gets bigger and bigger. First of all, merging would create this additional merge commit, which might be unnecessary. Secondly, it creates the problem of so-called spaghetti commit history. If you perform too many merge operations in your project. This is how our project history might look like. Now, if you were to take a look at all the historical commits made, maybe let's say that you have run git log command in the master branch. All you're going to see us bunch of merge commits. You do not get to see the changes introduced an individual branches. You have to navigate through the parent hierarchy to be able to look at all the branch related changes or comments. This is going to create a lot of confusion. Rebus put sort of address these problems that we see with merge commits. In order to understand how rebates exactly works, let us assume that we haven't performed the merge of these two branches. And this is the current state of our project. Now let us assume that I'm in feature one branch and I've run the command git rebase. What good would now do is first of all, it will try to find the common ancestor of both the branches, which in this case is N3 commit. And then it will temporarily store all these changes introduced in feature one. Somewhere in the repository. It would then point the feature one branch to the tip of the master branch, which in this case is m phi commit. Git will reapply all those stored commits one-by-one. This is as that we have created the branch AT MY commit and introduced all those feature lead to changes in feature branch. Earlier our feature branches based out of M3 commit. Now after running the rebase command, it is now rebased to m phi. Now, while doing this operation, you might as well see conflicts. We can resolve them just as we had resolved conflicts in case of merge operation. We went to see an example of that in upcoming lectures. Now if you take a look at this diagram, you notice that we can actually perform fast forward merge like so. Now guess what? No additional comments were introduced. An allo commits are linear with merge operation. If you had that problem of spaghetti commit history with rebase, we have linear development like you're seeing here, which makes it easier for us to take a look at commit history. And if you were to run git log command now, you will not only see how the changes introduced in master branch, but also all the feature related comments as well in linear fashion. Now you might be thinking that we can start using rebase and we would never have to use merge ever again. You could be wrong. There are certain scenarios where rebase is ideal thing to do, and there are other set of scenarios where much is a better option. You'll understand more about it Up next. 42. 0412 Performing Rebase in VS Code: Alright, let us take a look at an example of git rebase. But before that, let me walk you through the current state of our project. I have actually created a brand new project for this purpose and I've made a bunch of commits. Let me just walk you through what exactly I have done. Since the master branch as part of the very first commit, I have just introduced these TXT files, admin inventory and product dot TXT files. And in each one of those files, I've just added couple of lines of text as if we have written some code. The next commit went inside the master as well. And before that, I have of course created a branch that is based off of the very first commit. As part of the second commit, as the message suggests us, admin Edits and master. I've just added one line of text inside the admin dot TXT file, like so. And then I made my first commit in the feature branch and does the message suggests inventory edits from feature one branch. I just added one line of text inside the invented or TXT file. Next time made commit in master branch. And this time I have added one line of text in the product dot TXT file. And then I made one more comment in the feature branch where I have edited the product dot TXT file. Down the line. When we perform the rebase, we're going to have conflicts in product dot TXT file because we have one commit done in master where we have edited product dot TXT file, and same is done in the feature branch as well. Next time made one more committed master branch. Well, this is not really needed for me to explain this, but I've done this comment just so that the graph would look the way we want. Basically currently this blue line is representing the master branch, whereas the red line is representing the feature branch. However, this may not be the case always. Whichever branch we make the latest commit that would be shown first. For example, if I were to make one more comment feature branch, feature branch would be turning blue and master branch would be turning red. It might look confusing. And that's why I have added this additional commit so that the master branch would show up first and then the feature branch. Now before we proceed any further, It's really important for you to understand what exactly is going on and what are all the changes we have introduced in each one of these commits. So I'm going to make this project available for you to download. You can just import it into Visual Studio code and take a look at all the list of changes, understand it, and only then do proceed. Otherwise, you will start to confuse yourself. If you're able to follow along, that's great. If you're not, then take a pause, understand what's going on here, and then continue watching. So as you can see, feature one branch is currently based out of the very first commit on master branch. We now want to rebase feature one branch to the latest commit off master branch. How do we do that? Well, let's right-click on the very latest commit, the master branch. And then we have this option called rebase current branch on this commit. The current branch is master branch. When to switch to feature branch. And we know that we have pushed to feature one branch because this circle right here is pointing to feature one branch earlier it was pointing to master branch. Now let's right-click on latest commit off master branch and choose this option that says rebase current branch. On this, the current branches feature one branch. And this should ideally rebase unless we have conflicts. Of course, we're going to see conflicts because as I've mentioned before, we have edited product dot TXT file in both the branches. So let's click on rebase. As you can see, we have conflicts. Let's dismiss this. Well, we should ideally be seeing those files with complex let me refresh. And there you have it. You can resolve the conflicts and the way you want. In my case, I just want to accept both the changes. Save the file. And then I'm going to press this plus icon to stage this file. And then I can click on this check icon to actually proceed with the rebase operation. And the message that gets populated by default here is the message of the commenting feature, one branch that is actually creating the conflict. We get this editor opened. But I'm just going to leave the message as is, close the file. And this should finish the rebase operation. As you can see, the first four commits are off master branch and the other two comments belong to the feature branch. Now we can go ahead and perform the Fast Forward March. So I'm going to switch back to master branch. Right-click on this commit. And then I can choose merge into current branch. So I want to merge feature one branch into the master branch. I don't want to create a new commit for fast forward merge. So that's how you perform rebase. And if you notice, we have this linear development, which is what we're expecting with rebase. I'll see you next. 43. 0413 Git Rebase in Git Bash Skipping conflicts and Aborting the Rebase: Alright, let us see how we can perform git rebase from Git Bash. Currently we're in master branch me to switch to feature one branch to be able to run that command. And by the way, have brought back the project back to how it looked like at the beginning of our previous video. So that we can redo things and see how it works from Git Bash. I'm going to switch to feature branch. It can simultaneously observe what's happening in this graph. Git rebase. Where do I want to rebase to do a commit? That master branch is pointing to someone to say Master. And as you can expect, we're going to see the conflicts. Let us go ahead and dissolve them. In my guess, once again, I wouldn't accept both the changes, save the file, and go back to Git Bash, went to stage that file, git add product dot TXT file. And then we need to run this command. Git rebase, hyphen, hyphen continue to continue performing the rebase. And I'm going to do just that. You also have the option to skip. If you run this command, git will just simply skip the commit that is causing the conflicts. It is as though you haven't made the commenting feature branch that is causing the conflicts. If you run this command, maybe after successfully performing the rebase, you may want to reapply all those changes manually. However, since we have resolved the complex, you don't have to use this option, but feel free to experiment with it. Once I run this command. Again, it's going to show us the message. We can keep it as it is. Or if you wish to change it, you can go ahead and change it. Let's close. And as you can see here, we have rebased our feature branch with the master branch. Let's now go ahead and perform the merge part, which we're going to switch back to master git merge feature one. And as you can see, both the branches are matched. If a bone from git log command now, you're going to see all the commits introduced in both the branches in linear fashion, which is what we need. And by the way, well-performing rebase operation. And for some reason you have decided to abort it, then you can use this option, git rebase, hyphen, hyphen I bought. I'll see you next. 44. 0414 Git Interactive Rebase: Hold that, let us talk about interactive rebase. And for this purpose I have 1 second brought back the project to what it was earlier. Before performing the rebase operation. Let me switch to feature one branch and perform the rebase. I want to right-click on the latest commit off Master, click on rebase current branch on this comment. But this time I'm going to choose this option which says blonde interactive rebase in new terminal. This is equivalent to running the command git rebase with dash, dash interact to option. Let's click yes rebase. And this time we'll open up the text editor. Here you're going to see holders list of commits that are part of the feature one branch. What interactive rebase would allow us to do is we can actually perform a lot of customization based on our needs. If you see we have bunch of commands here, which we can use to tell git what we want to do with the commits or feature one branch. By default, this command is used pick, which means we want to use that committee. What that essentially means is we want these comets of feature one branch to be candidates for the rebase operation. But you can change this command to something else based on your requirement. For example, maybe I'd like to use this command reward, which means use commit, but added the commit message. Essentially, if you'd like to change the message to something else, then you can use this command. Let's, I want to change the message of this particular committee. And let's do that. I would like to use this drop command. To drop this particular commit. I know that this comment is going to create conflicts because we edited product dot txt file in this commit. So I'm going to drop this. Likewise, you got a bunch of other commands which you can use. You can just go through the description and see if they fit for your needs. Save the file and close it. So we're going to see another prompt asking us to chain the message of that commit. If you remember what this particular commit, we had used the command reward. That's where I get this prompting us to chain the message to something else. You can change this to whatever you want. Of course, don't say blah, blah, type something meaningful. I want to save the file and close this. So this time if you notice we only have five commits. Because we dropped one of the commits in feature branch where we made changes in product dot TXT file. And also for the other commenting feature, one branch would change the message to blah, blah. So go ahead and try and experiment with interactive rebase. I'll see you next. 45. 0501 Git Rebase vs Merge: Let's talk about git rebase. Git rebase is sort of like an alternative to merge. It serves pretty much the same purpose as with merge operation. But that being said, you cannot replace one with the other. We cannot replace VBS with the merge, and vice versa, we cannot replace merge with the rebase. It has its own pros and cons and each has its own purpose. And that's what we're going to talk about in this lecture and the next couple of lectures. First of all, let us try and understand what exactly is rebase. In case of three-way merge, GET request to create a merge commit whose snapshot would constitute the changes of both the branches. While this doesn't sound like a problem, we do start to see some problems with it, especially when our project gets bigger and bigger. First of all, merging would create this additional merge commit, which might be unnecessary. Secondly, it creates the problem of so-called spaghetti commit history. If you perform too many merge operations in your project. This is how our project history might look like. Now, if you were to take a look at all the historical commits made, maybe let's say that you have run git log command in the master branch. All you're going to see us bunch of merge commits. You do not get to see the changes introduced an individual branches. You have to navigate through the parent hierarchy to be able to look at all the branch related changes or comments. This is going to create a lot of confusion. Rebus put sort of address these problems that we see with merge commits. In order to understand how rebates exactly works, let us assume that we haven't performed the merge of these two branches. And this is the current state of our project. Now let us assume that I'm in feature one branch and I've run the command git rebase. What good would now do is first of all, it will try to find the common ancestor of both the branches, which in this case is N3 commit. And then it will temporarily store all these changes introduced in feature one. Somewhere in the repository. It would then point the feature one branch to the tip of the master branch, which in this case is m phi commit. Git will reapply all those stored commits one-by-one. This is as that we have created the branch AT MY commit and introduced all those feature lead to changes in feature branch. Earlier our feature branches based out of M3 commit. Now after running the rebase command, it is now rebased to m phi. Now, while doing this operation, you might as well see conflicts. We can resolve them just as we had resolved conflicts in case of merge operation. We went to see an example of that in upcoming lectures. Now if you take a look at this diagram, you notice that we can actually perform fast forward merge like so. Now guess what? No additional comments were introduced. An allo commits are linear with merge operation. If you had that problem of spaghetti commit history with rebase, we have linear development like you're seeing here, which makes it easier for us to take a look at commit history. And if you were to run git log command now, you will not only see how the changes introduced in master branch, but also all the feature related comments as well in linear fashion. Now you might be thinking that we can start using rebase and we would never have to use merge ever again. You could be wrong. There are certain scenarios where rebase is ideal thing to do, and there are other set of scenarios where much is a better option. You'll understand more about it Up next. 46. 0502 Performing Rebase in VS Code & Handling conflicts: Alright, let us take a look at an example of git rebase. But before that, let me walk you through the current state of our project. I have actually created a brand new project for this purpose and I've made a bunch of commits. Let me just walk you through what exactly I have done. Since the master branch as part of the very first commit, I have just introduced these TXT files, admin inventory and product dot TXT files. And in each one of those files, I've just added couple of lines of text as if we have written some code. The next commit went inside the master as well. And before that, I have of course created a branch that is based off of the very first commit. As part of the second commit, as the message suggests us, admin Edits and master. I've just added one line of text inside the admin dot TXT file, like so. And then I made my first commit in the feature branch and does the message suggests inventory edits from feature one branch. I just added one line of text inside the invented or TXT file. Next time made commit in master branch. And this time I have added one line of text in the product dot TXT file. And then I made one more comment in the feature branch where I have edited the product dot TXT file. Down the line. When we perform the rebase, we're going to have conflicts in product dot TXT file because we have one commit done in master where we have edited product dot TXT file, and same is done in the feature branch as well. Next time made one more committed master branch. Well, this is not really needed for me to explain this, but I've done this comment just so that the graph would look the way we want. Basically currently this blue line is representing the master branch, whereas the red line is representing the feature branch. However, this may not be the case always. Whichever branch we make the latest commit that would be shown first. For example, if I were to make one more comment feature branch, feature branch would be turning blue and master branch would be turning red. It might look confusing. And that's why I have added this additional commit so that the master branch would show up first and then the feature branch. Now before we proceed any further, It's really important for you to understand what exactly is going on and what are all the changes we have introduced in each one of these commits. So I'm going to make this project available for you to download. You can just import it into Visual Studio code and take a look at all the list of changes, understand it, and only then do proceed. Otherwise, you will start to confuse yourself. If you're able to follow along, that's great. If you're not, then take a pause, understand what's going on here, and then continue watching. So as you can see, feature one branch is currently based out of the very first commit on master branch. We now want to rebase feature one branch to the latest commit off master branch. How do we do that? Well, let's right-click on the very latest commit, the master branch. And then we have this option called rebase current branch on this commit. The current branch is master branch. When to switch to feature branch. And we know that we have pushed to feature one branch because this circle right here is pointing to feature one branch earlier it was pointing to master branch. Now let's right-click on latest commit off master branch and choose this option that says rebase current branch. On this, the current branches feature one branch. And this should ideally rebase unless we have conflicts. Of course, we're going to see conflicts because as I've mentioned before, we have edited product dot TXT file in both the branches. So let's click on rebase. As you can see, we have conflicts. Let's dismiss this. Well, we should ideally be seeing those files with complex let me refresh. And there you have it. You can resolve the conflicts and the way you want. In my case, I just want to accept both the changes. Save the file. And then I'm going to press this plus icon to stage this file. And then I can click on this check icon to actually proceed with the rebase operation. And the message that gets populated by default here is the message of the commenting feature, one branch that is actually creating the conflict. We get this editor opened. But I'm just going to leave the message as is, close the file. And this should finish the rebase operation. As you can see, the first four commits are off master branch and the other two comments belong to the feature branch. Now we can go ahead and perform the Fast Forward March. So I'm going to switch back to master branch. Right-click on this commit. And then I can choose merge into current branch. So I want to merge feature one branch into the master branch. I don't want to create a new commit for fast forward merge. So that's how you perform rebase. And if you notice, we have this linear development, which is what we're expecting with rebase. I'll see you next. 47. 0503 Git Rebase in Git Bash Skipping conflicts and Aborting the Rebase: Alright, let us see how we can perform git rebase from Git Bash. Currently we're in master branch me to switch to feature one branch to be able to run that command. And by the way, have brought back the project back to how it looked like at the beginning of our previous video. So that we can redo things and see how it works from Git Bash. I'm going to switch to feature branch. It can simultaneously observe what's happening in this graph. Git rebase. Where do I want to rebase to do a commit? That master branch is pointing to someone to say Master. And as you can expect, we're going to see the conflicts. Let us go ahead and dissolve them. In my guess, once again, I wouldn't accept both the changes, save the file, and go back to Git Bash, went to stage that file, git add product dot TXT file. And then we need to run this command. Git rebase, hyphen, hyphen continue to continue performing the rebase. And I'm going to do just that. You also have the option to skip. If you run this command, git will just simply skip the commit that is causing the conflicts. It is as though you haven't made the commenting feature branch that is causing the conflicts. If you run this command, maybe after successfully performing the rebase, you may want to reapply all those changes manually. However, since we have resolved the complex, you don't have to use this option, but feel free to experiment with it. Once I run this command. Again, it's going to show us the message. We can keep it as it is. Or if you wish to change it, you can go ahead and change it. Let's close. And as you can see here, we have rebased our feature branch with the master branch. Let's now go ahead and perform the merge part, which we're going to switch back to master git merge feature one. And as you can see, both the branches are matched. If a bone from git log command now, you're going to see all the commits introduced in both the branches in linear fashion, which is what we need. And by the way, well-performing rebase operation. And for some reason you have decided to abort it, then you can use this option, git rebase, hyphen, hyphen I bought. I'll see you next. 48. 0504 Git Interactive Rebase: Hold that, let us talk about interactive rebase. And for this purpose I have 1 second brought back the project to what it was earlier. Before performing the rebase operation. Let me switch to feature one branch and perform the rebase. I want to right-click on the latest commit off Master, click on rebase current branch on this comment. But this time I'm going to choose this option which says blonde interactive rebase in new terminal. This is equivalent to running the command git rebase with dash, dash interact to option. Let's click yes rebase. And this time we'll open up the text editor. Here you're going to see holders list of commits that are part of the feature one branch. What interactive rebase would allow us to do is we can actually perform a lot of customization based on our needs. If you see we have bunch of commands here, which we can use to tell git what we want to do with the commits or feature one branch. By default, this command is used pick, which means we want to use that committee. What that essentially means is we want these comets of feature one branch to be candidates for the rebase operation. But you can change this command to something else based on your requirement. For example, maybe I'd like to use this command reward, which means use commit, but added the commit message. Essentially, if you'd like to change the message to something else, then you can use this command. Let's, I want to change the message of this particular committee. And let's do that. I would like to use this drop command. To drop this particular commit. I know that this comment is going to create conflicts because we edited product dot txt file in this commit. So I'm going to drop this. Likewise, you got a bunch of other commands which you can use. You can just go through the description and see if they fit for your needs. Save the file and close it. So we're going to see another prompt asking us to chain the message of that commit. If you remember what this particular commit, we had used the command reward. That's where I get this prompting us to chain the message to something else. You can change this to whatever you want. Of course, don't say blah, blah, type something meaningful. I want to save the file and close this. So this time if you notice we only have five commits. Because we dropped one of the commits in feature branch where we made changes in product dot TXT file. And also for the other commenting feature, one branch would change the message to blah, blah. So go ahead and try and experiment with interactive rebase. I'll see you next. 49. 0505 Rebase to specific commit or to another feature branch: In this video, we're going to take a look at how we can rebase to a particular commit us. We don't have to necessarily rebase to the tip off a branch. We can also do base to a particular commit. Currently or feature one branch is based out of the very first commit of the master branch, but I can rebase it to the second commit off master branch. In Visual Studio Code, I need to switch to that branch, which I want to rebase. I choose feature one branch. Once I do that, I'm going to right-click on the commit where I would like to rebuild the feature one branch two. And then I can choose this option that says rebase current branch on this commit. If you were to do the same from the Git Bash here to fast-twitch to feature one branch. And then you're going to say git rebase. And then the hashCode of the commit that you'd like to rebase to. In this case, it's going to be the second commit of master branch. I'm going to copy the first few characters of this commit, like so. Go back to Git Bash, paste it here. And this should now rebase feature one branch to this comment. Well, this diagram may not look so obvious. But if you notice, we have the feature one branch, which is based out of the second commit off master branch. These two commits that belonged to the master branch are not part of the feature one branch. As expected, the graph would look more obvious if we make another comment in master branch. So let's do that real quick. I'm going to switch back to master branch. I'll just add a line of code, product file, saved the file. Let's go back here and commit these changes in master branch with the message. Now if you go back to the graph, we have master branch in blue and feature branch in red. But if you notice feature branches now based off of the second comment on the master branch, because we have rebased it to that. And we do not necessarily always have to rebase to the master branch. We can also the best a particular branch to another branch which is not a master branch. Let me show you what I mean. First of all, let us create a new branch. But this time, instead of creating a branch at the tip of the master branch, I'm going to do that at this particular commit. And yes, we can also create new branches that are based off of a particular commit. I can just right-click on the commit where I would like to create branch from. And then click on Create Branch, enter the name of the branch, and we're good. But let's see how we can do the same from Git Bash. Let me switch to master, for instance, git branch, and then the name of the branch that would like to create. Let's call it feature two. And then you're going to specify that come up based on what you'd like to create this branch. I'm going to copy the first few characters off this commit object. Go back to Git Bash, paste it in here. We'll actually, if you run this command, you don't really have to switch to master brands. You can run it from any other branch. So we now have a branch created that is based out of this particular combat. And you can see that branch here. Let's make a commit in this branch. For that, let me switch to feature two branch. Go to maybe a product file. Product changes from feature to whatever. Save the file. And let's commit these changes in feature to branch. If you notice, the first line is representing the feature to branch, and it is based out of the third commit of master branch. So that's FY21 be hash, which we've entered previously. And then this red line represents the master branch, green represents the feature one branch. If you want this graph to look more obvious, let us make a commit in master branch. Once again. Let's commit these changes with the message. If you go back to the graph, you would see that we have the master branch, feature branch of feature one branch that is based out of second commit and feature two branch that is based out of the third comment. Now let's go ahead and read best feature one branch to the tip of the feature to branch. Let's first switch to feature one branch. And then I'm going to right-click on this commit. Rebase current branch on this committee. We have conflict. Let us quickly resolve them. Accept both the changes saved the file, stays the file. And then committed. This should open up an editor. Just close it. And this would finish the rebase operation. Once again, the graph may not look so obviously does make one more comment. In master branch. I'm going to switch back to master branch, go-to product dot TXT and just add one more line of code. I'm going to use the same text as the commit message. And let's commit at this time, if you notice, the first line is representing the master branch. But the point here is we were able to rebase feature one branch at the tip of the feature to branch. So these two commits belonged to pitcher one branch which will just rebased to feature two branch. Now if you wish, you can just go ahead and merge both these two branches and delete one of them or do whatever. If you want to do the same from Git Bash than you'd just switch back to feature one branch, git rebase, feature two. And this should rebase your feature on branch at the tip of the feature to branch. Since we've already done that, I don't have to run this command. But I hope you got the point. So do go ahead and experiment with this, play with everything I've just discussed. If you do not practice, everything would look countries and ensuing, you would start to get frustrated. See you next. 50. 0506 When to use rebase and when to use Merge usecases: So rebase or merge. Let's talk about it. Imagine that this is the current state of your project. You have created a feature branch out or the very first commit on master branch. And then you've got a bunch of commits made in master branch after creation of the feature branch. Now let us say that for some reason you realize that you're too early to create that branch. Maybe you needed some of the changes introduced in master branch that came after you created the feature branch. Guess what? You can just rebase the feature branch to a specific commit that came afterwards, so that you will have all those changes in master branch, which would be available in feature branch. This is one use case where you might want to use rebase over a merge. Another use case off rebase. Let's say that you have created couple of branches like you're seeing here. Now, let's say that you have realized that these two branches aren't supposed to be in two different branches. They might be addressing the same issue or they might belong to the same feature. So maybe you'd like to have them as part of a single branch. Guess what? You can just rebase one of the branches with the other one, like so, and you're good to go. However, there are certain scenarios where rebus is not the best option. Rebase you're altering and rewriting the good history. Every time you rebase, you're rewriting the Comment objects pointing to a different parent. That's not the case with much. You're going to retain the commit history and gets off merge. And that is a reason why you should avoid using rebase. If there are multiple developers working on a single branch. For example, imagine that we have duller and duller B2, and then we also have the centralized repository. And this is the current project structure. In all these places, we have the master branch with couple of comments and feature branch with a single commit. Now, let's say that dollar per one has rebased to a different commit. It won't be reflected across all the other system. For example, all the other developers, and even in the centralized repository. Now, long story short, this is going to create lots of inconsistencies and might as will destroy the very purpose of why we have rebase, which is to have a clean commit history. As a rule of thumb, just remember, if you're the only one who is working on a particular branch, a feature branch, Let's say we can then use rebase before actually pushing that code into the centralized repository. If there are multiple developers involved and they're all are contributing to the same branch. Then merges option for you In that case. I'll see you next. 51. 0601 What is Stashing It's usecases Example of Stashing: Let us talk about stashing. Let us I'm currently working on feature one related changes. And so I'm currently in feature one branch. Now, while I'm still working on this, my boss comes to my desk and asked me to continue working on feature two and deliver it first before working on feature one, maybe that customer is eagerly waiting for feature too. Now, in hope for an appraisal, I might say yes to my boss and I would not want to start working on feature too. But what if I have some uncommitted changes in feature one? Let me actually go ahead and make some changes in one of these files. As if I'm introducing some changes related to feature one. I'm just simply going to add one line of text, like so, save the file and close it. Let me go back to Git Bash. So we have some changes introduced for feature one. And then now wanted to work on feature to let me switch to feature to branch. So I'm currently in feature to branch. Now, if I open up this file admin dot TXT, would you be seeing the changes that I've just introduced? Let us take a look. You still see these changes. That's because between branches carries all those uncommitted changes with you. These are the changes that are related to feature one. And I'm able to see it even after switching to feature two. Now why is this a problem? Well, when you're working on feature to related changes, this might actually create a lot of confusion, especially when you're trying to stage all those files related to feature two. You might come across with changes related to feature one and might end up confusing yourself. So what is the solution here? One solution is obviously to commit feature one related changes before you switch to feature two branch. But that's not a solution because we're not done with feature one changes either. Well, how about we have the feature which allows us to store all our uncommitted changes temporarily somewhere in the repository. And then we'd be able to retrieve them whenever we want. That's exactly what is stashing in Git. I'm currently in future one branch. So before I switch to feature two and start working on it, I would like to stash all our uncommitted changes. The command for that is good. Stash. Now, this command will only stash the tracked files by default. To make a file tracked by Git. As you might have already know, we need to stage it at least once. So if we have a brand new file which was never staged before, then we cannot stash it. If you want to stash all those untracked files as well, then Inuit include an option. Include hyphen untracked. Need to run this command with this option so that both staged as well as I'm staged changes, even the new files which are never tract before, would be stashed. Alternatively, the shorthand for this option is just simply to use hyphen new. Currently we do not have any files that are untracked anyway. So we see a message that says Saved working directory and index date. Wip stands for working progress on feature one branch. And it is pointing to the latest commit of feature one branch, which means this command has stashed changes that came after the latest commit, that branch. Now if you open up admin dot TXT file, you would no longer see all those changes because those were just stashed. Now we're free to switch to feature two branch. And here I work on feature to related changes or make bunch of commits. And once I'm done with it, I can again go back to feature one. And I can retrieve all those stashed changes with the command git stash, pop. Let's run this command. The good pop command. After retrieving all those uncommitted changes back again, it will delete those changes from the temporary store. But behind the scenes, essentially it has created a commit object, and this is the hashCode off it. And this commit object will not be part of any branch. History, is just a temporary commit object created along with it snapshot just for the purpose of stashing. And as you can see by this line, this commit object has been dropped. If you open up admin dot TXT now, you can again see all those changes that were previously stashed. There are other bunch of use cases where it gets stashed might come in handy. We will export them in our coming lectures. I'll see you next. 52. 0602 Applying the stash across multiple branches: There might come a time or a use case where you might need to apply the same changes across multiple branches. In which case git stash pop doesn't serve the purpose. When to use git stash, apply for the same. Let me show you what I mean. I'm currently in future one branch and we have certain uncommitted changes. Let me go back to Git Bash and stash all those uncommitted changes. So we took a backup of it and we would no longer see these changes. Now let's do git, stash, apply. And let's see what it's going to do. Once again, good has brought back all those uncommitted changes from the temporary store. But this time it didn't delete all those changes from the temporary store like it did in gas off git stash pop. Which means we can apply those changes in another branch as well. But before that, let me commit all these changes. Let's say I'm done with all the changes related to feature one. Stage those files first, and then commit the changes. Let me now switch to feature two branch git stash. I can now run the apply command to apply all those stashed changes. Once again, currently we don't have all those changes in future to branch. But once after I run this command, you're going to see those changes here. 53. 0603 Retriving a specific stash Listing stashes Handling conflicts: Let us see how we can take a look at list off stashes and be able to retrieve a specific stash? Yes, it is possible. Let me show you what I mean. In order to explain this better, I have once again brought back the project to what it was at the start of this chapter. So we basically have no stashes whatsoever. I'm in feature one branch. Let me go ahead and edit one of the files. Let me just simply add one line of text, like so, save the file, close it, go back to Git Bash and let us stash those changes. Go back and open up the file. Would no longer see all those changes because those were just stashed. Let me add one more line of text, like so, saved the file, close it. Let me stash these changes as well. Now, we have done stashing couple of times, and this must have been maintained somewhere in the repository. How do we take a look at it? The command for that is git stash list. This would list on all the list of stashes. We can retrieve a specific stash by using its ID. But if you notice, the message is in here are not very descriptive. This is just the latest commit on feature one branch and same as used for all the stashes. Now, over time, as your stashes gets increased, it might be difficult to identify would stash has which changes? Fortunately, git allows us to give a descriptive message while we're stashing. So let me edit another file. Maybe invented or TXT like so. And I'm going to do the same for product file as well. Save it and close it. So I have just made edits and couple of files. Let me stash those changes, but this time I'm going to give a descriptive message. Save is the option we need to use and you're going to provide some message, something like that. Our changes are stashed. To take a look at the list of stashes. Now, you're going to see a descriptive message. Now let me try to retrieve this particular stash. Once again, we can either pop the changes are applied, the changes. Let me apply the changes. I wanted to specify the idea of the stash like cell. You can see the changes were retrieved and are applied. Similarly, we can also retrieve this particular stash. And we're going to see those changes in admin dot TXT file. But let us see what would happen if I were to retrieve this particular stash where we have edited the exact same file. This operation, I really should fail. And sure enough, we have an arrow that says your local changes to the following files would be overwritten by merge. Please commit your changes are stashed them before you merge. So basically this Stash is going to react to the changes which might conflict with our existing uncommitted changes. So what is the solution for? The solution is already provided here. We can commit all these changes or stash them once again and then retrieve this particular stash. Or alternatively, we can just use the command git restore dot to just wipe out all the uncommitted changes. And that way we should be able to retrieve a specific stash without any problem. But then we have also lost all the changes. We're actually going to talk about how we can handle conflicts while stashing. When we talk about git pull in later chapters. I'll see you next. 54. 0604 Stashing Selective Changes and retrieving them Understanding Hunk: It's not necessary that we have to stash all the changes. We can also be select to ask to water all the changes we want to stash and changes that we don't want to stash. And once again, for the sake of this example, I've brought back the project to what it was at the start of this chapter. So we do not have any stashes at the moment. Let me edit couple of files. Like so. I saved the file. But this time, let us stash partial changes. This time I'm going to use the option hyphen P stands for partial. And let's see what it allows us to do. It has provided us bunch of options. If you don't know what these options are about, you can just type in question mark and you'll be able to see a description of it. So basically this command would prompt you all the changes that we have done one by one. And we can tell what to do with those changes based on these list of options. So currently it is pointing to this particular change belonging to inventory dot TXT file. If we type in y, it's going to stash the hunk. You can think of hunk as a change which is being presented here. So this is a new line of texts would have just added. If you type in N, That means you don't want include it as part of stash. It means that you don't want to stash these changes. Q as in quipped, do not stash this hunk or any of the remaining ones. But what are all the hunks that you might have said yes to what still be stashed upon quitting. Essentially, we're going to exit out of this operation while also stashing all the changes that we said yes to here would mean stash this hunk and all later hunks in the file. In the same file. D would mean they're not stashed this hunk or any of the later hunks in the file, it is opposite to option a. He would mean manually edit the current hunk. This is something we would never use. I've personally never used it. I don t think of a use case to use this. Basically, if we want to edit anything, we would rather do it in walking down a tree and then stash the changes. So let's say that I'd like to stash these changes. So I'm going to say y here. Then it's going to prompt us with the second hunk, which belongs to product dot TXT file. And these are the changes. Let's say that I don't want to stash someone to say n to this. Let us do git restore dot to just clean our working directory. Let's call it with this command. We are deleting all those uncommitted changes. Let me try to reapply that stash. This command would just apply the latest stash we have in the list. But before I run that command, Let us make sure that our changes are lost. As you can see, our changes are not there. But once after run this command, we're going to see changes applied in inventory dot TXT file. Because this hunk was stashed. Where does in product dot TXT file, we don't see any changes. I'll see you next. 55. 0605 Exploring stashing in VS Code Deleting a stash: Now let us take a look at how we can perform stashing Visual Studio Code. And once again, for this purpose, I brought the project back to what it was at the beginning of this chapter. And we currently have no stashes whatsoever. Let us go ahead and make edits in couple of these files. May add a line of text like so an admin dot TXT file. And let me do the same in inventory dot TXT file, saved the file. Let's go to Source Control. Click on these three dots and you see the option to perform stash. So here you find a routine we've learned so far in this chapter. We can perform Stash. Stash, which also includes untracked files. We can apply latest stash. This is as good as we're running git stash apply command. Or we can choose this option that says apply stash. And then we get to choose the one of the saved stashes. Let's go ahead and perform stashing. It is asking us to enter a message, let Center or something, hit Enter. So this must have saved how changes. 1 second, Let's go to stash. We can click on Apply letters stash, or we can choose this option that says a plus stash. And then we get to choose the stash that we would like to apply. Currently, we just have one stash and say it is getting displayed. If we had list of stashes, those would be displayed as well. Let me click on this. And as you can see, changes for now applied in both these files. Let's see what other options we have. We also have the option to pop the latest stash, pop a specific stash. Or we can even drop this dash or drop all the stashes. Essentially drop would mean deleting a stash. This is similar to running the command git stash drop. And then you're going to specify this dash ID. Or you can just say git stash, clear. And this would delete all the stashes. We can either do it from here or we can also run the command. Let me run the command. Now. If I do git stash list, you're not going to see anything because we have just deleted everything. But that's how you use stashing in Visual Studio Code. I'll see you next. 56. 0701 Git Ignore and it's significance (Crash course): Let us talk about gitignore and its significance. There might be certain set of files which you do not want to commit or you do not want them to be available for others to download and use. Some of the examples of such files are as follows. We might have log files that are generated during runtime. And obviously we do not want to commit them and make them available in centralized repository for others to download. Similarly, we might have compiled code like dot class files or dot p-y, C files, etc. Or you might have local dependency folders like Node modules in case off node projects. But we can ignore these files by simply not staging them and not committing them. But there might be instances where people tend to accidentally commit some of these files, thereby creating a mess which is not intended. So gitignore file comes in handy there. Gitignore file will allow you to specify certain patterns. And all the files and folders that match with those patterns would be ignored for staging of accommodating. If you try to stay as the files that match with these patterns specified in dot ignore file, you would see an error. Let's take a look at a couple of examples of such patterns. When you say star dot log for instance, star is considered a wildcard character. That means you can have any file in your repository or your project with any name. As long as it has dot log extension, those files would be ignored. So here are some of the examples of files that would be ignored when you have this pattern specified in the doubt ignore file. We have added dot log in the root directory and then info dot log under logs folder. Both these files would be ignored. Let's take a look at one more example of a pattern. We have lungs slash. When you specify a slash, that would mean a directory. This pattern would essentially ignore all the contents, including sub-directories of all the folders with the name logs. And here are some of the examples of files that would be ignored with that pattern. Pause the video, take a second and try to understand this. All these files belong to Logs directory. And so all these files would be ignored. We cannot stage them, and so we cannot even come at them. Let's say that you have this project structure. Typically we tend to have one dot ignore file and that would go inside the root directory of the project. However, it doesn't prevent you to have dot ignore files in the subdirectories as well. The dot ignore file and it's patterns is applied on the folder where it is residing, including its sub folders. So all the patterns in the dot ignore file residing in sub one folder are only applicable on sub one folder. And all its subdirectories, including all the files. But it's not applicable on its parent folder, which in this case is my app folder. There might be instances where you might have conflicts of patterns. For example, we could be having a pattern that might be conflicting in these two dot ignore files. In which case the patterns of sub one folder will have higher precedence over the patterns in my app folder. We're going to take a look at an example of this up next. And thereby you will have better clarity. If you have any patterns that are not applicable for the entire team, but are only applicable in your local enrollment. You can mention the mass part of the exclude file. And the fact that this file belongs to dot git folder means that this cannot be worsened or you cannot commit these changes. And for all the patterns that are applicable for entire team, that's a dot ignore file would come into picture and it is versioned, meaning that once you make an update in dot ignore file, you would commit them and actually push all those changes to the centralized repository so that everybody else would download the Dart ignore file. And all the file patterns in that file would be ignored for everyone. So nobody would be able to commit all of those files which are not meant to be shared across the team. You can also specify global patterns that are applicable in all the projects are repositories in your local enrollment. You can do that by running this command that you're seeing here. This would essentially add one additional configuration in the Git config file residing in the user's directory. I'll see you next. 57. 0702 Git Ignore in action Global exclude config: Let us say git ignore an action. What we have here is our good old my app application with bunch of files and maybe with bunch of commits as well. Forget about all the commits we made and just don't care about the files in it. Let's just stay focused on gitignore. Now imagine that I have downloaded this project from the centralized repository and even launch the application. When I do that, I might end up seeing that in log files getting generated automatically by the application. Now since we do not have it running application, let us simulate the behavior by manually creating the log files. Let me create maybe either dot log file. Here it has deemed that this file is actually how to create it by the application. May also create a folder with the name info where we might have in for logs. So let me create a file with the name in for dot log. Like so. Now if I launch Git Bash, I can actually stage these files. Git add dot log. As you can see, I'm able to stage this file, which is not something that I want to do. So let me quickly onstage this file. Now how do I prevent myself from accidentally staging these log files? Well, one solution is you go inside the dot git folder info. And then we have this exclude file where you can specify the patterns that you want it to ignore. So we could specify a pattern star dot log, and that way we cannot stage them or commit them. But this time we don't want to use this file. Can you guess why? Because these log files is not something that is local to my enrollment. It is applicable for all the team members in the team. Anybody in my team who downloads this projects and runs the application, there'll be able to see these log files. I don't want them either to be able to commit these files and centralized repository. Well, that's where gitignore comes into picture. So let me create dot gitignore file, dot git. Ignore. Make sure that you get the name correct. Let's open that file and add this pattern star dot log. So this should ignore all the log files in our project. Now if I go back to Git Bash and try to stage this file, it actually going to see an error that says the following parts are ignored by one of your dot ignore files. If I still want to add this file anyway, then I can use this option hyphen F to four-stage this file, which was meant to be ignored. But you do not want to do this unless you know what you're doing. We cannot even stage for dot log that's inside the info folder. We get the same error. And if you have any files that you want to ignore and you want all those patterns to be applicable across all the repositories in your local machine. Then you want to specify global exclude file with the command git config global. And then you're going to say core exclude file. And here you would provide the path, the dot ignore file. Once you run this command, global Git config file would be updated. That is inside your user's directory. I'm actually take you there. So currently just has the global credentials that I want to use for all the repositories in my local enrollment. But once after you run this command, you're going to see this particular property getting populated in this file. Whichever they ignore file it that it is pointing to, its patterns would be applicable for all the repositories in your local machine. Generally speaking, you want to specify the patterns that are relevant to the operating system files like dot, DS, store, et, and not project-related files. Since we don't have anything, I just want to not run it. Once after you create or update the dot Git ignore file, you want to commit those changes and even push your changes to the centralized repository so that all those patterns would be applicable for all the people in your team. We're going to talk about how you can push your local commits to the remote repository in later chapters. But for now I can go ahead and come in the gitignore file. Git add, git, ignore status, git commit, hyphen them, whatever. And we're able to commit this change. I'll see you next. 58. 0703 Precedence order overriding Pattern debugging: Let's talk about precedents. Let us say that we have one more dot gitignore file in one of the subdirectories. Let me actually copy this file into info directory like so. But instead of this pattern, I want to have this pattern. Or this pattern means is we want to ignore all the files that does not have dot log extension. Now if you notice we have a conflict in patterns. In the root directory. We have a pattern that says we want to ignore all the dot log files. But whereas here with this pattern, we're saying we want to ignore all the files. That is not a dot log file. Which pattern should get follow. That's where the precedents will come into picture. In this case, this pattern would be preferred over the one in the parent directory. The way it works is when you have a file like info dot log in, it will check to see if there are any dot gitignore files in the same directory where that file is residing. If there is, then it will try to find patterns, a matching with that file. If there are no patterns that match with that file, then it will look for patterns in the parent directory. If it still doesn't find there, then it will try to find the patterns inside the exclude file. If it doesn't find patterns over there as well that matches with the particular file. Then it will go inside and check the global ignore file. If we had configured it. If it doesn't find anywhere, then it will allow us to stage that file. That's how precedent would walk. Now if I go to Git Bash, Let's see if we can stage the info dot log. We can, as you can see, we are indeed able to stage info dot log because the pattern in that folder, sales that we want to include this file and don't want to ignore it. In most cases though, typically in almost all the projects, you would only have one dot gitignore file and that goes inside the root directory. But I'm sharing this just for your information. I should also mention that we're not restricted to a couple of patterns. We have bunch of patterns which we can use depending on what are all the files that you want to ignore. In most cases, it would typically be this. Or you might end up specifying a folder like so. All of the patterns you can refer to the official documentation. There aren't many. Can just have a quick look and get a sense of weight as patterns that are supported. It doesn't make sense for me to walk you through each and every pattern and take up all your time. Just refer to the documentation and it has all the things you need. Sometimes you might have so many ignore files. That makes it hard to understand why a particular file is being ignored. In which case we have one command handy. You said Get, check. Ignore with hyphen v option stands for verbose. And then you're going to specify the name of the file. For example, Error dot loc. And this is going to print why this file is being ignored. As you can see, we have dot ignore file in the root directory. And this pattern is matching with this file. And that's why it's being ignored. This might come in handy, especially if you have multiple ignore files or you're not sure of why a particular file is being ignored. 59. 0704 Ignore files that were already committed: What if we had already committed the changes would supposed to be ignored? Let me show you what I mean. For this purpose. Once again, I have brought back the project to what it was at the beginning of this chapter. We once again have these three files and we'll start from there. Let me go ahead and create one log file. Let's call it error dot log. Let me actually go ahead and commit this log file. As if I'm committing this file accidentally, along with bunch of other changes. Git add error dot log, git, commit Typhon, some message, and we have committed the log file. Now imagine that our project is very new, Our team is very new. Nobody is familiar with dot ignore file. And so let's say we have a bunch of files in the repository, are in the centralized repository committed by bunch of folks would supposed to be ignored. Now it is at this point in time I have realized that I needed to have dot gitignore file in my root directory. So I'm going to include it dot Git, ignore. I'm going to specify a bunch of patterns, which I wanted to ignore. In my case, I'm just simply going to say star dot along. Like so. Let me rename this file correctly. It's supposed to be good. Ignore like so. Now it's already too late because we have already committed all the files that are not supposed to become at it. Let me actually come at this file as well. Git add, git, commit Typhon am introducing ignore file. Now I have introduced this file, which is great. And this will now ignore all the files that are supposed to be ignored. But how about all the files that were already committed? How do we get rid of them? Well, one simple solution is to just simply pinpoint all those files, delete them, and then make a commit. All those files will be deleted. And from now on we have the dot gitignore file, any way to prevent that happening. But practically speaking, if you've got lots of files, it becomes really impractical to pinpoint all the files that you wanted to get rid off. Do we have a better solution? The answer is yes. We have a sneaky work around to solve this problem more effectively. Let me show you what I mean. I'm going to go back to Git Bash. Let me clear the screen. Let me do git status to make sure everything is clean. Now let me run the command. Git RM, hyphen r stands for recursive. And then I'm going to use the option cached, followed by a period. What am I trying to do here? I'm actually trying to delete all the cached files. Now, water cached files, you might ask me, well, cached files are essentially the files that are being tracked by Git. Git stores all the files it wants to track in a cache. And with this command, we're cleaning them up. This gives an impression to get that we have actually deleted all the files without actually having to delete from the working directory. Let's run this command and see what happens. And as you can see, it has removed all these files from the cache. So this includes literally all the files in our working directory. As you can see, we have five files here. And we have five files here. Next, what we're going to do is we're going to actually stage all the files sensing what's going to happen. But before that, let me run git status command once again. And this time if you notice under changes to be committed section, it has listed all of those five files. That's because get us thinking that we have actually deleted all those files. Although we haven't deleted them from the working directory. We just clear the cache and made good belief that we've actually deleted those files at the same time. Under untracked files section has listed all the files that are currently not being tracked. Now, do take a note. This list doesn't include error dot log because it is now part of the pattern inside the dot gitignore file. Git doesn't want to track it. Now let us go ahead and add all these untracked files and make them tracked by Git. Git add this term. I'm going to use period character so that even the files that start with dot would be added and are tracked by Git. Now if I do git status, you'll see that error dot log is the only file which we need to come in. This is as if we have deleted this file and making a comment. Essentially with this, we're able to delete all the files that are not supposed to be committed are the files that are supposed to be ignored. Now since we have this pile staged to be deleted, There's one last thing we need to do is to commit the changes. Cleaning up ignored five, It's like cell. And get has deleted at a dot log. Would just simply means that the new snapshot does not have this file anymore. But of course we still have it in the working directory. So this is just a sneaky work around to get rid of all the files that we had previously commented which are supposed to be ignored. Now if you're still unclear, take your time and experiment with these commands and you'll understand them. I'll see you next. 60. 0705 Generating the Ignore files for your project: If you're introducing the dot gitignore file in your project, you don't really have to brainstorm as to what patterns you want to keep in that file. You can just simply use one of the existing tools with a quick Google search git ignore generator. I came across with this link. It stopped al.com. You could be seeing some other website, but they do the same job of generating patterns for you depending on the kind of project you're building. For example, let's say that I'm building an Android application. So I'm just simply type in Android and click on Create. And it has provided me list of patterns that I can add as part of my projects dot gitignore file. We're already familiar with majority of these patterns. All the lines with hash would mean comments. Here we're trying to ignore DOD Gradle directory. Here we are trying to ignore the build directory. So all the contents of it, all the files as well as the sub-directories would be ignored for staging. Here we're trying to ignore the local dot properties file. Star dot log would mean we want to ignore all the log files. And we've already seen an example of the same. Similarly, we've got a bunch of other patterns. Let's try typing in Node. And let's see what it's going to generate. Once again, we have bunch of patterns which you might want to add a new node JS project has an assignment. Just copy one of these files and try and experiment with these patterns and see what are all the files that are being ignored and motor all the files not getting ignored. I'll see you next. 61. 0801 Why GitHub GitHub vs Bit Bucket vs GitLab: Alright, it is now time to talk about GitHub. We sort of already touched on this at the beginning of the course. But let us try to reiterate and try to understand the need to have a centralized code hosting service like GitHub. If you're the only one who is working on the project, then you do not need something like GitHub. You can just get away with Git that is installed locally to manage the versions of your project. However, as your project grows bigger in size, you might want to hire additional people who can contribute to your project. Though just one or two people, then you can easily manage without having to use a service like GitHub. Tens and hundreds of employees who might want to contribute to your project, then you surely need a better way to manage your code and it's version history. And that's where GitHub would come into picture. And GitHub acts like a centralized code repository where everybody would contribute their code. Essentially, they make bunch of commits in their local Git and then upload or push all those changes to the centralized repository. And then everybody else would be able to download all the changes introduced by other team members. Say everybody would essentially have a copy of the entire project on the local computer. As well as we also have a copy of the project in the centralized repository like GitHub along with its version history. And that's what I get is called a distributed version control system. However, get is not just about being able to host your code or maintain version history. It offers a lot of other features which are pretty useful for an organization. For example, being able to manage team members as to who can do what. Are being able to review the changes introduced by one of the team members before merging them into the mainstream of development. You can do pretty much everything what you can do in your local good software, like committing the code, creating branches, et cetera. It will also offer you to comment on somebody's work. We can also discuss things over community, etc. Now GitHub is not the only option for us. We've got other players as well in the market which saw the exact same purpose. Which one you want to use is entirely dependent on your requirements. If your organization is using Atlassian ecosystem projects like Jira, bamboo, et cetera, then Bitbucket might make sense to you because it has better integration with those tools. And amongst all of these three, git lab is open source. The other two have both free and paid tiers. And get lab and Bitbucket has better support for continuous integration, which is a concept of DevOps up discussed it in my DevOps course. But GitHub is the oldest among these three. There are millions of projects that rely on GitHub and there are millions and millions of developers across the globe who are actively using GitHub. Github has amazing community and is also the best choice for open-source projects. User interface is also quite minimalistic, but it comes with a cost, though. It doesn't have the integrated support for continuous integration like with GitLab and Bitbucket. But it's okay, you can use some of the third-party tools for that. But it doesn't matter which one of these tools you will learn. They ultimately have the same goal of managing your project. They might differ in terms of user interface and terminologies that are being used. But otherwise, they all have the same purpose. 62. 0802 Creatig GitHub Account: Okay, let us see how we can create a GitHub account and even create couple of repositories. For this purpose, I've actually created a fake Gmail account, which is under Corp 96 at gmail.com. As if this company is established in 1996 or WhatsApp. Now cylinder as a freelancer, he's going to create a GitHub account for his own organization so that everybody else and his team can now start contributing to the project in GitHub. Let's click on sign up. Actually, the instructions are pretty straightforward. I don't really have to walk you through this, but I'm just doing this as a formality. So it is asking us to enter the email address. I'm going to do just that password. I already have it handy. So I'm just going to paste it. Username is going to be some there Corp 96. And get up says that this is not available. So we need to change this to something else, maybe 1996, now it's available. Let's continue. It is asking us if we would like to receive the updates and announcements via e-mail, I would say no for now. If you wish, you can opt in for that. Next. It is asking us to solve a puzzle to make sure that we're not a bot. I just have to choose this spiral galaxy. In my case. I'm going to do just that. I've done an excellent job there, so I can go ahead and create the account. We received this email with the code, which I just have to copy and paste it here. And we're done with creating GitHub account. Pretty much. I just wanted to skip this step. If you wish, you can choose how many team members you have and whether you're a student or a teacher. But I'm just simply going to skip it for now. And we're done. Now at the very first glance off this welcome page that you see once after you login for the first time, get up is already giving us suggestions as to what we can do next. We can create repository or import existing repository. We can introduce a read me file in our project. We can even explore the options to contribute some of the existing projects, which we'll talk about at later stage in the course. And there are bunch of other things which you can just take a look at and get a sense of what they're about. You don't have to go too much deep because we're going to explore everything in upcoming lectures. 63. 0803 Creating and understanding Public and Private repositories in GitHub: Okay, let's see how we can create GitHub repositories. We can add that important existing repository. I'll create a new one. And I'm going to do just that. Here. You're going to see the name of the owner. In this case, we just have one owner. And that is what is chosen by default. Here you have to provide the repository name, the name of the repository that you'd like to do. Now, we have to make up your mind whether you want to make the project public or private. If your aim is to initiate an open-source project, then it might make sense for you to choose the public option here. Or if you're an organization where your software or the application is proprietary and you have a client for whom you're working for, then it might make more sense to use a private repository. If it is a public repository, anybody from across the globe would be able to view the content of your project, download your project, clone it, et cetera. Whereas if the repository's private, you can choose as to who can do what you can contribute to the project, who can view the project, etc. I'm going to demonstrate the creation of both. The repository is assuming that I'm creating some kind of an open source project. Let me call my app as my public app or whatever. If you wish. You can also separate these names with a hyphen. You cannot have a whitespace character. If you do include whitespace character, then get would automatically assume a hyphen character, like it is suggesting. By the way, I might use the word Git and GitHub interchangeably depending on the context. So this is the name of the app which I've given. I can also write a quick description about the project, my public app, whatever. And then get up. It's showing us options to include some of these files, like Read Me file, which would have some details about the project. The dot ignore file, essentially whatever the file patterns you include in this file, would be ignored to be committed. Then we can also choose the license file. There are certain predefined licenses which we can use if we wish. For example, if you're creating an open-source project, than gpu or general public license might make sense to you. For the time being, I'm not going to choose any of these because we can add them later. But if you choose one of these, then get will automatically create a commit on our behalf committing these files. It's your choice. You can choose it or not choose it. Both are pretty much same. We're going to add them anyway in coming lectures. So this is just simply going to create a public repository. Let's click on Create Repository. And GitHub is providing some next steps which you don't have to bother about because we're going to explore them anyway in coming lectures. But if you go back here, you can see that our repository is listed here. If you copy the link, the link would look something like this. You have GitHub.com and then the username slash, the name of the repository. And that's how everybody would be able to access your public repository. Now, anybody across the globe can actually hit this link to be able to view Watson's our project because it is public. Let's now also create a private repository. You click on new name of the repository is going to be say, bank app, whatever. My banking application, I'm going to choose the option private, so that only the people that I give access to be able to view the project and contribute to it. I'm actually talking about collaborators, which we will explore pretty soon. This time. Let me maybe choose one of these files. Maybe I would like to add a license file. For instance. This probably cannot be a general public license. But you can use just anything. You don't have to be really serious about it unless you are a real organization who is worried about licensing. I'm just simply choosing something random and create repository. This time, github has made one commit for us. And in that committed has committed the license file. You can click on that file to take a look at its content. You can change this if you wish and make another commit. But we're going to explore all that in upcoming lectures. Let's go back to the homepage. And now you can see these two repositories. Now since this is a private repository, this cannot be accessed by anybody else. Unfortunately, private repositories and GitHub doesn't have a lot of features that public repositories have. If you want those features and private repositories. And more, hint actually consider taking some of the paid tiers offered by GitHub. Unless you are an organization, it doesn't really make sense for you to pay for them. And for that very reason, for the most part, we're going to be using the public repository in this course. I'll see you next. 64. 0804 Making Commits in GitHub and Understanding ReadMe file: Let's see how we can make our first commit and get up. And we're going to do that in the public repository. What we're going to come at is the read me file for our project. Now what is the read me file? Whatever you want to let know, the contributors of your project would go inside the read me file to understand it better, let's take a look at some of the existing projects and GitHub and how depopulated the ReadMe files. I'm just simply going to choose one of the random projects. So I click this link that says find reports that need your help. I'm just simply going to choose one of the random projects available here. Maybe this here are the list of tuples to raise. Both are public. Let me choose this one. All the projects and GitHub would most likely will have the read me file. And it typically goes inside the root directory of the project. So here it is. Let's see what's inside it. Basically can write stuff like your contact information. Some of the links that you want to share with the dollar bills. Or you can instruct them as to how they can raise issues and whom to contact to incase if there is some issue with the application. You can also talk about the application and its features, like they're doing here. Here are the list of features supported by this application. They're showing instructions as to how they can download this project. And bunch of other information that we're sharing their roadmap so that developers will have the bird's-eye view of the entire project. Here they seem to have listed all the list of contributors, or maybe top contributors who contributed to this project. So on and so forth. Let's go ahead and create a read me file in our public repository. I'm going to choose the public repository that were created. And currently we do not have any commits. We can either create a new file or upload existing file, or we can choose one of these options. And gate will pre-populate with some content. We've already seen that in case of license file, we already have some pre-defined templates. We also have certain predefined are pre-populated templates for dot ignore file as well. But we're not going to use that because we haven't yet talked about it. Let me choose Read Me file. So it's Read Me dot md file. It's taught MD extension. Here. You can write whatever you want to write. And once you're done, you can scroll down and click on this button that says commit new file. Here you can see that some default message is populated already by GitHub. It says Create, Read Me dot RMD file. If you wish to change it, you can go ahead and change it. You can also add the description about that commit. But I'm happy with the default message. So I'm just simply going to leave it as it is and click on Commit. No staging step is required. This would internally do that job for us. Once you commit the file, you're going to see that file here. Let's make one more commit by introducing one another file. Let me go back and click this option that says Add file, create new file. Maybe I would like to add in four dot TXT file, some content info file. Let me expand this. I'm going to scroll down. And 1 second. I'm happy with the prepopulated text, but I can change it to something else if I wish. I'm going to leave this option as it is. Since we haven't talked about pull request. I cannot explain you right now as to what this option is about. We're going to talk about it in coming lectures. Come with the new file. Now we have a couple of comments. If you click on this commits, you can see the list of commits we have done. Here's the hashCode off each one of those comments so you can copy them by clicking this icon. You can also go to a state of a project at a particular commit. By clicking this. For example, if I click on this, comet will come at the ReadMe file. At this point we don't have the info file, so we don't see it. Let me go back. Here. You get to choose the branch. Currently we just have one branch and that is the default main branch. Otherwise you'd be seeing list of branches and we'd be able to switch to one of the branches. So that's how you make comments and GitHub. We created the repository and also have added some of the basic files which makes it ready for others to contribute to our project. I'll see you next. 65. 0805 Creating Branch and committing changes Managing branches in GitHub: Okay, let us see how we can create a new branch and even make comments in it inside GitHub. For that, let me go to one of the repositories. I'm going to be using the public repository for this. Here you get to see a list of branches. Currently we just have one branch, the main branch, which is also the default branch. Here you can see this link that says view all branches. You can either click here or you can also click this link that says one branch. It says one branch because we currently have one branch. Let's click on this link. Here you see the option to create a new branch. Just click on this button, type in the name that you'd like to do to that branch. Something like that. You can also choose the source branch from where you want to create this branch. In this case, we just have one branch and it has defaulted to the main branch. I'm going to keep it as it is and click on Create Branch. This has created the branch for us. You can also see specific list of branches. For example, if I click on activate, this is going to list on all the list of Act two branches. Or in other words, these are the branches where there is at least one commit made in past three months. You're not going to see the default branch though. You can see the branch that will just created. This tail branches is the opposite of two branches. If there are any branches where you haven't made any commits in past three months, you're going to be seeing a list of them here. If you're the owner of the repository, maybe you'd like to get in touch with collaborators are developers who are working on these branches and check with them if they still want to keep these branches or not. You'll get better idea about it as we progress in this course. And the branches in this section would be listed in a manner that the branch with the oldest commit would be listed first. Whereas here in the active section, all those branches would be listed in a manner that the branches with the recent commit would be listed first. If you click on all branches, this foot just show the default branch, followed by all the other branches ordered by the branches with the most recent commit first. You can also delete a branch and you can restore it. If you delete a branch, refresh the page, then it's too late to restore it. So we're able to create a new branch. Let us go back to the repository. Here we get to choose the branch that we wanted to switch to. Switch to feature branch. This is as if we have run this which command or checkout command mentioning the branch name. And if you notice, we now have two branches showing here. We can either add a new file in this branch or edit one of the existing files. Let's try to add it. Read Me dot MD file. I click on this icon, which will allow me to edit some message. I want to scroll down. I'm happy with the default message if you wish, you can go ahead and change it. I'm going to leave this option as is. And click on Commit Changes. This has committed how changes in the new branch. We're currently in main branch. And if you click on Read Me dot md file and check its content, you would notice that it doesn't have the changes introduced in new feature branch. But if you switch to feature branch, as you can expect, you're going to see the changes that we've just introduced and feature branch. I'll see you next. 66. 0901 Cloning a public repo and exploring other options: Earlier we had created a GitHub account with the name Centre Corp 1996. And we've also created couple of repositories. One is public, the other one is private repository. Or public repository should be available for anybody in the world to view, download, flown, et cetera. Now let's say that I found a guy with the name Luke and I wanted him to contribute to my public repository. Now imagine that I'm inside the Luke's computer. What you need to first do is basically to have GitHub account. So for this purpose, I have actually created a new Gmail account with the name look Centre Corp at the red gmail.com and its corresponding GitHub account as well. So this is Luke's account and now he's preparing himself to contribute to the cylinder cop 1996 public repository. This is the URL of that repository. And I'm able to view the project and its content because this is public repository. If this is a private repository, then I won't be able to view this. In fact, anybody with this link should be able to view the project and its content because it is public repository. Now the first thing that loop needs to do to start contributing to this project is to have local copy of this repository in his local computer. What I'm talking about is git clone. And as the name suggests, it would essentially cloned the center repository or the project into your local enrollment. So you click on this button that says code. And we have multiple ways to clone the project. We can do it through, get up CLI. Get up CLI is a tool offered by GitHub. It's an open source tool and it would essentially allow you to interact with GitHub from your computers command line. But this tool is originally meant to save some time, but this is not a mandatory tool as such. The other option is to use SSH, which is a lengthy procedure because for this, you have to create public and private keys and then store the public key in the repository, et cetera. Talking about SSH should be a topic of another course. If you're using SSH, then you can go with this option. If not, then we have a better option. In fact, this is option recommended by even GitHub, which is to use HTTPS protocol. This is best option amongst all these for two good reasons. Number one, typically firewalls do not tend to stop as HTTPS traffic. So we have an advantage there. Secondly, it will also help the credential helper off your operating system to be able to cache or stored the passwords, which is not the case with the other two options. This is simplest of all, and we can blindly go with this and don't have to worry about SSH or get up CLI. We also have the option to download the project. Well, if you download the project is not going to download the historical data or the version history is just going to download the files in the project. We can also open this with GitHub Desktop. If you have the GitHub Desktop installed, you can open it up and then you get to choose the folder where you want to clone this project. Since we're not using this tool at the moment, we can ignore this. So what we're going to do is just simply copy this HTTPS link. This is the exact link, as you're seeing here, which is the link to the repository, That's github.com slash username of this repository, the owner of the repository, slash the name of the repository itself, and then dot get extension. This is essentially what is this? You are literally just copied. Once we have this link copied inside our local computer, I'm inside def directory. Let me copy it again. You can't imagine that this is Luke's computer. I'm going to use the command git clone. And then you're going to paste that URL. So here it says cloning into this folder. Essentially it has created folder with this name, which is the exact name of the depository. And the contents of it would constitute exactly the contents that we've seen in GitHub repository. And if you notice it has actually compressed all the objects. Basically to make it easy to transfer all the files over the Internet to your local computer. And then finally, it has extracted all the objects. A total of nine objects have been received. Let's take a look at the content inside that directory. So here's my public cap. Let me enlarge it a little bit. As you can see, we have been put out dxdy as well as Read Me dot TXT file. Inside dot git folder. You're going to see what we usually see. You might have observed couple of things which might look strange to you at this point in time. We're going to talk about them in coming lectures. For example, we have so-called remotes, which weren't available when we locally created the repository. We'll talk about them in coming lectures. This is as you have created a local depository, except this time, we have actually cloned an existing repository from GitHub. If you were to download the project, you're not going to see the dot git folder. You would only see these two project files. Now this is the reason why it is called distributed version control system. You have a copy of the entire repository along with its version history in your local machine. And you also have a copy of it in the centralized repository, which is get up. And everybody in the organization or in your company would be having a copy of the entire repository. If one were to go down, then you have other systems from where you can recover them. That's distributed version control system for you. Let's go back to Git Bash. Now if I run the command git branch, we need to first go inside that directory. My public CAP, git branch. You're only going to see the main branch, although we have created feature branch in the centralized repository GitHub, here we're only seeing main branch. Why is that? Well, you will find answer to it in upcoming lectures. 67. 0902 Cloning a Private Repository and adding project collaborators on GitHub: Okay, let's see how we can clone a private repository. Currently I've logged in as sender, who is the owner of these repositories? One is the public repository and the other is the private repository. We've already seen how we can clone a public repository. Anybody in the world can actually view it, clone it onto the system. But when it comes to private repository, not everyone can actually access it or be able to clone it unless sender address them as collaborator of their project. In order to demonstrate this, I've actually logged in as both cylinder as well as Luke, who'd be contributing to the private repository of cylinder. In order to distinguish between these two accounts. The one with the black team belongs to sunder and the one with the white team belongs to Luke. Now you need to make an assumption that these two people have actually logged in from their own computers. And of course not from the same system, like we're doing here. Let me copy the link of the private repository and tried to access it from Luke's account. And we get an error that says 404. This is not the webpage you're looking for. That's because under hasn't given permission to look to access this project. So what sender needs to do is you need to go into that repository, go to settings, and then add Luke as contributor. Let me enter the password real quick. You'll see this option that says Add People. I'm going to search for. Looks under carp. Since Luke has a content, github, will be able to see him. Let me choose them and click on Add looks on the Corp to this repository. Once we do that, loop will actually receive an e-mail to accept the sun does invitation to be the collaborator of sender's private repository. So let me click on this link. Click on Accepted Mutation. Now if you go to the dashboard of Luke, you can see that private repository getting populated. Let me click on it. I can now go ahead and plot this project. But it's not very straightforward as with public repository, we have to actually authenticate it. Let me demonstrate it for you. So this is looks computer. Let us assume I'm inside the F drive. And let's run the command git clone and paste the URL and see what's going to happen. Well, good opens up this particular prompt. And there are multiple ways we can authenticate. But I'd like to go with this option that says sign-in with code. If you choose sign in with your browser, you'd just be taken to a web page where you'd be asked to login to your GitHub account. And that way you'll be authenticated and cloning process will continue. But let's try to choose this way. When I click on Login with code, you're going to see a code that we need to use to authenticate. Let me open up a browser window first. I'm going to go to github.com slash login slash device. It will take us to this page. Let me copy this code, control C and control V. And click Continue. Click on Authorize. Does asking us to enter the password of Luke's account. Let's do that real quick. That's all. Our cloning process has continued. And we can now start accessing the bank app. Groups lists with the hyphenate option, but also show the hidden folders. From this point on, everything would remain as is as with the public repository. But that's how you clone a private repository. I'll see you next. 68. 0903 Understanding Tracking Branches and Default branch : Let's talk about tracking branches. Imagine that this is the current state of our project in GitHub. And now let's say that I have run the git clone command to clone the project into my local computer. Now, this is what is going to happen in my local computer in no particular order. Initially all the objects would be downloaded and then get will create so-called tracking branches. Now what is the tracking branch? Tracking branches, a local branch that represents a remote branch. And it would always point to the exact same commit. The remote branches are pointing to there just representing the remote branches. Just to recall, a branch is simply a pointer to a specific commit. Now, these tracking branches won't be updated automatically. They will be updated whenever we run certain commands like git-fetch and git pull, which we're going to talk about in coming lectures. And then by default with clone operation, git checkout to the default branch, which is the main branch. And so a local Min branch would be created automatically. We can actually configure the default branch in our GitHub, will explode that in upcoming lectures. If you remember in our previous lecture, when we run the command git branch, it has listed just the main branch, but not the feature branch. Well, this is the reason for that. If you want to be able to see the feature branch as well, we have to check out to that branch so that a local feature branch would be created by good and would be able to see it. Now let's say that I've made a commit local in the main branch like cell, the tracking branch would remain as is, because that's what even the remote main branch is pointing to. But the local main branch would be updated to point to the latest commit in our local machine. You'll understand the significance of tracking branches when we explore commands like git-fetch, git, pull, git push, et cetera. Another thing you might have noticed is that all these tracking branches are named as origin slash main or origins feature. Well, what is origin here? It is essentially the earliest created by get that represents the remote repository. Basically whenever we run commands, winter provide the URL of the remote repository. It's really hard to remember the URL. And that's why we have this LES created. So that instead of using the URL, we could just use this name. Instead. We can change this name if we wish, or we can keep it as it is. We're going to talk more of it in upcoming lectures for sure. See you next. 69. 0904 Exploring Tracking branches Configuring Default branch Understanding Origin Head: Okay, let us first take a look at list of tracking branches. And the command for that is git. Branch. Hyphen r stands for Remote. Here you can see both the main branch as well as the new feature branch. And these are the tracking branches that will represent in the remote branches. In GitHub. You can say that these are tracking branches because they start with origin slash and then the name of the branch. You can also locate this in the Git repository. Let me go to the project. And inside dot git folder, you should be able to locate this file with the name packed hyphen drifts. Open that up. And you can see that we have these two branches. And the point into specific comments. Let's take a look at what they're pointing to. For that, let me go to get up. I'm currently inside the main branch. And here you can see the hashCode of the latest commit. It is E 0, triple six is seven. And we're in the main branch. And if you notice, the tracking branch main is pointing to the exact same comet. Let's check with new feature branch as well. It should point to this commit that starts with 855 D, D2. Let's go back and switch to feature branch or new feature branch. And sure enough, it points to this commit with the hashCode 855, double D to C. Even if you were to make a local commit, this would still remain as is. This would only be updated when we actually run certain commands like git, fetch, git pull, et cetera. We'll explore them in coming lectures. Git branch would list down list of local branches. And whichever is the default branch and GitHub would be checked not automatically whenever we clone the project, the default branch happens to be the main branch. The head here always points to the default branch, which is the main branch. Let's go to get up and take a look at where we can configure the default branch. If you go to the settings. Under branches. Here you'll see that the default branches, the main branch. If you wish, you can switch to another branch. For example, I can choose feature branch and click on update. But it's not a recommended practice. I'm going to skip it. But you can do it if you wish. Inside the Git repository. If you go inside refs remote origin and take a look at what's inside the header file, it should point to the default branch, like so. And that's what we're seeing here. Now, to create a local branch for the new feature branch, went to check out to that branch. Let's do git checkout. New feature. Now if you do git branch, it's going to list down all the local branches. And it now includes the new feature branch as well. We can now start working on this feature branch. You'll get better clarity on what we've just talked as we progress in this chapter. I'll see you next. 70. 0905 Understanding origin remote adding, editing, deleting remotes: Let's talk about origin. Origin is kind of like an alias on your system for a particular remote repository. Let me explain what I mean. There are certain commands and get where you'd be required to specify the remote repository URI. Like in case of git push. We're going to talk more about git push command in upcoming lectures. But essentially what this command allows us to do is it will allow us to push our local commits on to the remote repository. Well, such commands requires us to enter where we want to push our commits to by specifying the remote repository URI. Now how about we give some name to this ERA so that every time we have to run such a command, instead of specifying the entire ERA, would just need to type in that name instead. That's going to give us a lot of convenience. And that's essentially what is origin. Origin is kind of like a shortened name for the remote repo study that the project was originally cloned from. So that instead of entering the URI, we could just say origin, like so. And it is Asda. We have entered the remote repository URI. We can rename this name to something else. We can also add additional remotes. When I say remote is just simply a name representing a particular remote repository, how we can even delete these remotes. Let me demonstrate you what I mean. If you go inside the dot git folder, inside your project and open up the config file. You notice that we have one remote with the name origin, and it points to a remote repository in the URL field. This is exactly what is the mode. So every time we have to run the command, where would be required to enter the CR? We can just enter the name origin instead. We can also rename this, but of course, we shouldn't do it on this file directly. Instead going to run the command. Let's do that. Inside the Git Bash. Let us first create a new remote. And yes, we can have multiple remotes and there are scenarios where we might require multiple remotes. We're going to talk about it in upcoming lectures. But for now let us see how we can create a remote, rename it, and even delete a remote. The command for that is git remote. Add name of the remote, the name that you'd like to, to that remote repository. Let's call it temp, report, whatever. And then you're going to specify the URI of the remote repository. This is just a dummy URL which doesn't exist. And if I hit Enter, and if we go back to config file, you'll see that there's a new remote created with the name temporary pole, whose URL is the URL that we've just specified in the command. Let me try to rename this remote. Git remote, rename them ripple. The name of the remote would like to rename. And then you're going to specify the name that we would like to give it. New temp, repo, let's say. And this is going to change the name to that new name. Finally, let us see how we can remove a remote. Git. Remote remove is the option. Then you're going to specify the remote that you would like to remove. And that's it. This has removed remote. When we had run the clone command to clone a particular remote repository, git has essentially created a remote for us. The name of that remote is origin, whose URL is the URL we have used to clone the project. You'll understand more about remotes as we progress in this course. I'll see you next. 71. 1001 Understand Git Fetch and it's usecases: Let us talk about git-fetch. Imagine that this is the current state of our project in both remote as well as local depository. Now pause the video, take a minute and try to understand this diagram. You all renew this. Well, we just have a couple of comments in the main branch in both local as well as remote repository. And then we have single commit in the feature branch in both local and remote repository, except in local depository, we also have additional tracking branches that represent the branches in the remote repository. And currently they are pointing to the exact same comets that the corresponding remote repository branches are pointing to. Let's talk about git-fetch. Imagine that there are a couple of additional comments made in feature branch in remote repository. Now what if I would like to download the objects that correspond to these comets at the same time. I don't want to see all those changes in my working directory. Now, you might be having a question popping up in your mind as to why do we want to download these objects? But don't want to have those changes shown up in a working directory. Well, there are multiple use cases when it might be useful. For example, let's say that I would like to compare my local repository with the remote repository to check to see how many comments is the remote repository is ahead of my local repository in a particular branch, or vice versa. I would like to check to see how many comments is my local repository ahead of the remote repository in a particular branch? Or what if I would like to get the exact state of the remote repository as is in my local enrollment, to start working on it. At the same time. I don't want it to have any kind of implications on the work that I've already done locally. Or it could be the case that I just wanted to take a look at if there are any additional branches or tags, references that are present in the remote repository but are not present in the local depository. Well, git-fetch is the answer for that. When you run the git fetch command locally, it's going to download all those additional objects that are not already present in your local repository. And also update these tracking branches to point to this new commits or the new objects that just got downloaded with git-fetch. Now in this example, we're only assuming that we have additional comments and feature branch. And so only the tracking branch of feature branch is updated to point to the exact same commit that the remote branches pointing to. However, if there are additional comments made in other branches, their corresponding tracking branches in your local machine would be updated as well. Now the fact that the local branches, like the main and the feature branch are still pointing to the old commits. You'll walk in that room, will not have all those newly introduced changes. Now all this might sound very confusing to you, but in next few lectures, you'll have complete clarity as to why we need git-fetch and you'll understand its significance. I cannot fit everything under single video. I'll see you next. 72. 1002 Git Fetch in Action Part1 (Command variations Checking status with commands): Okay, let us see how git fetch works. I've currently logged in as the owner of the repository. And just for your information, currently both local as well as the remote repository are exactly same. No additional comments were made in either of the places. Let me now go to the public repository and make a new commit. We could actually do it in the main branch, or let's do it in the feature branch. I'm just simply going to add a new file. I would like to name it as maybe Apple dot dx, dy. It doesn't matter if you'd like to include a folder and just do the name of the folder. Maybe. Like send a new provider slash. This would create a folder with the name My Folder inside which will have this file with the name apple dot TXT. I just would like to comment the file. Click Commit. We have just created a comment. Let me now go ahead and create a branch as well. First let me switch to main branch. Because that's from there. I'd like to create a new branch. This type in the name of the branch that I'd like to do, maybe feature two. And then here we get an option to create a branch feature to, let's click on it. And this should create feature to branch. Let me switch back to new feature branch and click on list of comments. Here's the commit that we've just made, whose hash starts with E8, AF, whatever. Now let's go to the local enrollment. Now, you need to imagine that this is one of the employee's computer, maybe Mr. Luke's, whatever. Now before I do git fetch, Let me run the command git log. And notice that I'm currently in the new feature branch. Here. As you can see, that the new feature branch, which is the local branch, is pointing to this particular commit. And even the tracking branch is pointing to this commit. Now once after I do git fetch, it should download all those additional objects present in the remote repository and also update this tracking branch to point to that commit object. Let's see if that happens. But before that, let me down one more command to check the details of the origin remote. Git, remote, show origin. This will show the information about the origin remote. Let me walk you through what is being displayed here. We have the fetchone, which is being picked up from the config file, pushes something we haven't yet talked. But when we use the push command, this is a URL which should be used to push our local changes. Head branches pointing to the main branch, which has a default branch, as we've discussed before. Here are the list off branches. These are the branches that are available in the remote repository. If you notice, for the new branch which were created in the GitHub, Twitter to branch. It says next fetch will store in remote slash origin. What this means is when we do fetch, git will create tracking branch for the feature to branch which is present in the remote GitHub repository. However, the main branch and the new feature branch, what already been tracked. Here are the list of local branches configured for git pull. We're going to talk about good Pull pretty soon. These are the branches for git push. We don't have this branch here because we haven't yet fetch debt and we haven't checked out to that branch. Now let us take a look at what would happen if I do git fetch. Well, ideally I have to specify the name of the remote from where I would like to fetch the objects from. But if I do not specify anything, it would default to the origin remote, which we already have. If you'd like to fetch objects corresponding to a specific branch on a particular remote. Then the syntax for that is you're going to specify the remote origin in this case. And then you just specify the name of the branch, for example, new feature or whatever. If you'd like to download objects for all the remote and all the branches, then you just use the option. All. Currently we only have one remote villages origin. So I can just run this command as is without having to specify anything. So all those additional objects were being downloaded and are unpacked locally. And if you notice, we have this new branch, which is feature to branch for which at tracking branch is created. And then this is important line. The new feature branch. Earlier it was pointing to this particular commit. But now the new feature tracking branch, or the local tracking branch, is pointing to this new commit. This is the exact commit that we've made in the remote repository a moment ago. So here it is. It is E8 a F E to E. And this is exactly the same. Now let me rerun the remote show origin command and see what it has to show compared to what it has shown earlier. Well now if you observe the feature to branch is being tracked, but this branch is still not available in this list. That's because we haven't yet checked out to that branch. If I do get Switch feature two, or you could also say Git checkout feature too. We would switch to that branch. And now if you run this command, you would see that branch in that list as well. Let me switch back to new feature branch. Whenever I switch to that branch, you see this message that says your branches behind origin new feature, which is the tracking branch by one commit, which means remote repository is one commit ahead of our local depository branch. It is also saying that we can actually perform fast forward merge, which we're going to talk about in upcoming lectures. And it is also suggesting to us that we can use git pull to update your local branch. Once we update the local branch with good poll or with the merge operation, you're going to see all these new changes being available inside the working directory. Countries, since the local branches still pointing to all commit, your working directory is currently not impacted at all. If I do git log now, you only see that our local new feature branch is pointing to this old commit. Earlier, if you remember, we have also seen the tracking branch pointing to this commit. But after fetch tracking branches now pointing to that new commit object that was downloaded with git-fetch. I'll let, I'll see you next. 73. 1003 Git Fetch in Action Part2 (Exploring refs FETCH HEAD): Okay, I mentioned that git-fetch would download the objects and even upgrade the tracking branches. Let us say if I'm indeed correct for that, let me go to GitHub and copy the hashCode of the latest commit by clicking on this icon. And I'm currently in the new feature branch and GitHub. Let me go to Git Bash and let me try to pretty print this object, get kept file hyphen P. And then I'm going to paste hashCode that I've just copied. So we're able to see the contents of the commit object, which means git-fetch has indeed downloaded this object. If you navigate through this parent tree of this comet object, you should be able to locate the blob objects and its corresponding content as well. Now let us see if cracking branches are updated. I mentioned that the tracking branches are actually preserved in the backdrops file. Let's open it up. Here. If you notice, the new feature branch is still pointing the old commit. Now am I wrong in saying that tracking branches would be updated? The answer is no. Let us see what's there in this particular directory. Remote origin and new feature refs, remote origin. And let me open up the file with the name new feature. And here you see the hashCode of the latest commit. Now why is this hash code available here but not available in the refs file will typically get tend to store references in directory structure. It doesn't necessarily always store in packed file. Get to use this packed file for efficiency's sake. But it doesn't guarantee how he cannot even predict where it will store the references. It could be in the packed file, or it could also be in the form of a data structure. If it stores the differences in a packed file, it doesn't have to create the directory structure just to store the reference. It's all internal to get up. And this is one of the examples as to why we shouldn't be too much worried about how good does things for us. We just have to run the commands and trust and get on it. You might have also noticed this file, fetch head, which gets created when you do the fetch operation. Let us see the contents of it. Now this is again that you shouldn't be too much worried about. But if you notice we have three lines, each corresponding to individual branch, except the branch from where we had drawn the git-fetch command. All of the branches per marked as not for much. But again, let us not try to learn everything because you might end up confusing yourself and might end up not being able to understand the real concepts which are necessary. But this file typically be used by Gibbs. When we run certain commands like git pull for instance, which we're going to talk about in upcoming lectures. For example. If you do git log, you're not able to see the tracking branch or two which come at the tracking branches pointing to. But if you say git log and then fetch underscore head for instance. Then it will also list the comet object where the tracking branches pointing to like so. So similarly, we have certain commands which would internally use the fetch head file. I'll see you next. 74. 1004 Switching to Remote Repo State: Now with git-fetch, since we have downloaded all of those objects, we can actually check out the particular commit and going to detach that stayed. That way. We can have the same state of the remote repository without having to impact our existing work. Let me show you what I mean. Let me go back to GitHub and let me switch to new feature branch and get the hash code off the latest commit. Actually first few characters would suffice. Inside Git Bash. I'm going to say git checkout. There's the hashCode. So this should bring our project to detach that state. And essentially, our project isn't exact same state as with the remote repository. If you notice, we have this file, apple dot TXT file, which is what we need. If you read this message, you can see that it says you're in detach at state. You can look around, make experimental changes and commit them. And you can discard all those comments once you switch back to another branch. So I can go ahead and make some comments. Does the application or whatever vesicle experiment with my changes. And once I'm done, I can just switch back to a branch so that all those comments would be lost. In case if I want to keep those comments, then I can use this command gets which hyphen Z. And then I'm going to specify a name of the new branch. So this command would create this branch and have all those comments in their head is not pointing to this particular commit, not to a particular branch. And that's why it's detached head state. Let me switch back to new feature branch. New feature. And we exit from the detached head state. You would of course no longer CD apple dot TXT file. Now maybe you can take this as an assignment. Go to detach set state, make some comments before you switch back to a branch. Make sure those changes are, the comments are preserved in another branch. I wish you good luck with that. I'll see you next. 75. 1005 Merging the Changes Using FETCH HEAD: Let us assume that I would like to have all the changes of remote repository in my working directory. Maybe because I would like to work on them, or maybe it's just that I would like to have all the remote updates and then I would like to continue working on my own stuff. Now a question to you. What can I do right now so that I'll have all those changes in my working directory. With git-fetch. We have already downloaded all the objects. We don't have to do that again. What else can we do? Well, we can perform merge. We have the tracking branch for new feature which points to the remote commit. And we also have the local new feature branch, which points to the old commit. If we merge these two branches, we should ideally be having all the changes in our working directory, isn't it? First, let's run the command git status. It says your branches behind origin new feature by one commit and can be fast-forward it so good has given us a suggestion that we can actually perform fast forward merge. Which also means that there is also possibility that we might need to perform a three-way merge. And we might as well get conflicts, which we have to deal with. We've already seen how we deal with conflicts when you're trying to merge couple of branches. Same applies here too. Now can you try to make a guess as to what command me to type here to have all those new changes in our working directory. Well, it's a standard git merge command. We need to first push to a branch where we want to merge into, in this case, we want to merge changes from another branch to the local new feature branch. And that's where I'm at. Let me type in the command git merge. And I'm going to specify the tracking branch, which is origin slash new feature. Essentially we're just performing a fast forward merge in this case, wherein our new feature branch, which is a local branch, would now point to the exact same commit that the remote tracking branches pointing to. But let's say that you have a commit made in your local repository as well. Well, then in that case you have to perform three-way merge. And that might create additional merge commit unless you rebase and then perform a fast forward merge. Let's hit Enter. Here's a summary of what just happened. Our local new feature branch is not pointing to this new commit. The same commit that the tracking branch was pointing to. What just happened is fast-forward merge. And this is a new file we're going to see in our working directory. Here it is. I also quickly want to mention that the alternate to command for this is git merge, fetch underscore head. This will do the same job. And this is one of the commands where good might use the fetch add file. We had talked about earlier. Run that command. It says already up to date because we had already merged the changes. Hope it makes sense. I'll see you next. 76. 1006 Using Visusal Studio code to Fetch and Merge: Okay, let us see how we can perform fetch and basically written what we've learned so far in this chapter in Visual Studio Code. First of all, make sure that you have the project opened up. If you don't see your project here, go to File menu and click on Open Folder. Choose your project. And you should be good to go. Let us switch to source control section to perform git-fetch. Click on this icon. And then you see bunch of options. Go to pull, push section, and then you see the option to fetch the changes. Once you click on it for the first time, you might get a prompt asking you if you'd like Visual Studio Code to do that automatically every time, you can actually say yes to it, because git-fetch is considered safe operation. And since it's not going to have an implication on your working directory, you can perform it safely without having to worry about anything. And once you do that, you see a status here. In my case, I see one and then down arrow 0, and then apparel. I'm not sure if you're able to see this. But one down arrow would mean that we have additional commits in remote repository, which can be merged into a local depository. 0 or pyro means that we don't have any additional commitment or local depository that we need to upload our push to the remote repository. We're going to talk about how we can push our changes to the remote repository in upcoming lectures. Once you have that, let us say that you have decided to perform much. We're going to use this third party plugin for that. And here you can see that the origin new feature branch is pointing to this commit and our local new feature branch is pointing to this particular commit. Now guess what? I need to merge these two branches to have all the remote changes in my working directory. So in Visual Studio Code, I need to right-click on the branch which I want to merge. And then you see this option. Merge into current branch, our current branches, new feature branch as you can see here. So let's click on it. By the way, to explain things that have brought back the project back to how it was before merging. So right-click on it. Magenta current branch. We've already talked about this prompt. It's exact same prompt. Nothing different. But we don't want to create a new comment though. And now if you go to the working tree, you see this file, which is what we're expecting. 77. 1007 Updating Local References with Git Fetch: Let us say I would like to delete a branch on the remote repository. Now what would be its implications? Let's take a look. First of all, before you delete the branch, needed to make sure that all those changes are merged into another branch. You also need to discuss with all the people who are actively involved in contributing to that particular branch. Before you delete it. Let us go ahead and delete one of the branches. And I'm going to delete the feature to branch by clicking on this icon. You can also delete a remote branch from your local machine, will explode that in upcoming lectures. Let's say this is one of the developers computer maybe looks here if I run the command git remote show origin, you would notice that Git has shown this feature to branch as stale. And it has also indicated us to use this command git remote prone to remove this branch, promote local system. Alternatively, you can also run the command git fetch broom. With this command, git will connect to the remote repository. In this case, it would default to the origin remote. And then it will delete all the differences in your local enrollment that are no longer in use in the remote repository. Now, do take note that this command will only delete the tracking branches, but not your local branches. Your local branch would still stay intact. So let's run this command. So this has deleted the tracking branch. If you want to do the same from Visual Studio Code, just click on this icon. Go to pull, push section. And then you will find this option that says Fetch prune. That would do the same job as with this command. Now since you have a local pizza to branch still intact. And you might as well be having your own set of changes or commits in feature to branch. Well, you can push all those commits to the remote repository. And that way this branch would be recreated. Or you can also make those comments part of some other branch. We're going to talk about git push in upcoming lectures. But let's try to run this command again. And it would no longer see feature to branch under remote branches section. Let me go back to GitHub and restored this branch. Once again. Run the command Now. Then it says that when we do the next fetch, it would create a new tracking branch for the feature to branch. Let's do that real quick. And you can see that the feature to branch is now being tracked where essentially in the same state as with the start of this video. I'll see you next. 78. 1101 Understanding Git Pull: Let us talk about git pull. Now say it with me. Git pull is equal to git-fetch plus git merge or rebased depending on the option that we choose. That's essentially what is good Pull. Perhaps this is the shortest video of the entire course. However, it may not be so straightforward. We're going to talk about good pull in more detail in upcoming lectures. I'll see you next. 79. 1102 Git Pull in Action and observing what it does: Okay, Let us say git pull in action. I'm currently a new feature branch. Let me first try it on in the command git pull. And it says already up to date. That means there are no additional comments and remote repository that are not already present in our local repository. So that is first go back to remote repository and make a new commit in the feature branch or the new feature branch. I'm actually going to edit one of the files. It doesn't matter whether you add a new file or edit existing file. The point is to make a commit. So let me go ahead and click on this icon to edit this file. I'm not sure if you're able to see this. Let me zoom in a little bit. So let me just add one line of text, something of that sort. It doesn't really matter what you add. Click on Commit Changes. If you wish to attain the message, you can change it and click Commit. So we now have additional commit and remote repository, but that is not available in our local machine. Now before I run the git pull command once again, let me do git log and see what it has to display. As you can see, new feature as well as origin new feature, which is the tracking branch, are pointing to the exact same commit. Let me clear the screen and run git pull command. As you can see initially it has performed the git fetch operation and has unpacked the new objects. So these are the objects that got downloaded from the remote repository. There are total of three objects, which also includes commit objects, three objects, blob objects, et cetera. And then it went ahead and performed fast forward merge in this case. Because fast forward merge works in this case, we don't have any commits in a local branch. And so git has performed fast forward merge for us. Now if I do git log, you can see that the local new feature branch, as well as the tracking branch, are pointing to this new commit, which is exactly the commit which were made just a moment ago. It's f phi double d, whatever. And it's the same hashCode you see here. Earlier with git-fetch, our local branch was not updated. But with git pull, not only have we fetched all the objects and references, but also updated the currently checked dot branch. One thing I should mention is that all the good pull command would download the objects and references belonging to multiple branches or even remotes. It is going to perform much on the currently checked out branch. So when we did git pull, this is equivalent to git pull origin because this is only the mode which is currently configured and it is the default one. But if you wish, you can also specify the remote from where you'd like to fetch objects from. And then perform the merge on the currently checked dot branch, which in this case is new feature branch. I'll see you next. 80. 1103 Understanding Git Pull with 3way merge: Now let us see what would happen if we have commits made in both remote as well as local depository. This is to simulate a scenario where you might have commits made in your local repository, as well as few comments made in the remote repository might be from other developers as well. So in order to simulate this behavior, let us first try to make a commit in our local repository. If I run git pull, you see that our repository is already up to date. Let me quickly, I did one of the files here. Let's edit this file, for instance. Saved the file, stays the file. You can actually do all this from Visual Studio Code, but it's just my personal preference to do it from Git Bash. I feel more like a programmer when I do it from Git Bash versus using Visual Studio Code. So git add apple dot TXT. Good commit message. And we made our commit. Let us go to our remote repository and let us make some edits and input.txt file. Maybe I'd like to add one more line of text like so. And commit those changes. Now can you expect the behavior when we tried to do git pull? Now, imagine we perform git-fetch and then performed git merge. What is that you expect to happen is exactly what would happen if you run git pull command. Actually, we don't have to specify the mode. As you can see, it has prompted us to choose the message. Can you guess what this is all about? Well, this is the message get is asking us to go for the new merge commit object that it is going to create. This has essentially performed three-way merge. And get is now going to create the merge commit as well. Let's say I'm happy with this message. I'm just simply going to close that. And command would continue executing. This time. If I do git log, you can see that the local branch is pointing to the new merge commit. But the tracking branch, as expected, is still pointing to the commit that its corresponding remote branch is pointing to. This is the commit that we've just downloaded from the remote repository. Now, what if I do not want to have this additional merge commit created by git, rebase is the answer. And that's what we're going to talk about in our next video. I'll see you next. 81. 1104 GIt pull with rebase and it's implications: Okay, let us see how we can use rebase with git pull. If I run git pull command, you can see that it's already up to date. There are no additional objects to be downloaded from remote repository. But let me try to make a commit in the remote repository. And 1 second, I'm just simply going to edit this file and make a commit. Like so. Let me make a commit in our local depository as well. I'm going to edit this file using VI editor. You can use Notepad or Visual Studio Code. It's up to you. Get to stage this file, git commit. Now let's try to do git pull rebase option and see what's going to happen. Since trough performing the merge, get word. Now try to perform rebase. What this command does is it will download all the objects and commit. Essentially our local branch would be in the same state as with this branch in the remote repository. And then get will reapply all the local limit commits one by one. After it. I've me show you what I mean. So this has downloaded the objects and also performed rebase. But if you run the command git log now, you would notice that all these comments until this point are essentially the same as the commerce that we have in the remote repository. And on top of it, get has reapplied the locally made comments. This is same as you've cloned the project from remote repository. And then you made your local commits one by one. This can be better seen in Visual Studio Code with Git plug-in. So here we are. As you can see, how these comments at the bottom belong to the remote repository. You can tell it by looking at the auto section. So all these comments were made by Centre Corp. And on top of it, it has rebased our local commits on top of the remote commits. And that's why they came after them. But if you notice, we do not have that merge commit that we had earlier. But that's the purpose of rebase, which is essentially to not have those merge commits. Rebase essentially rewrites your commits and even hashCode wouldn't be same. For example, if you take a look at the latest commit you've made local depository, the current hashCode is phi to be whatever. If you were to take a look at this exact commit before rebase, the hashCode would have been different. Now this is the reason why all the rebased makes our commit history look more linear. It shouldn't rebase if you have all your changes already published in the remote repository. We're going to talk about git push and how we can push your local commits to the remote repository in upcoming lectures. And then you'll have better clarity as to what I'm talking about. I'll see you next. 82. 1105 Dealing with conflicts with Git Pull rebase: Let us see what would happen if there are any conflicts while performing it. For that, let me once again edit this file. I'm just simply going to add one more line of code, like so. And commit the changes. We have made edits an info dot TXT file. Let me read the same file even in my local repository or in my local computer. Let me add one line of text like so save the file, stage the file, and make a commit. New edit, info file, whatever. Now let me try doing git pull and we should get a conflict. I want to use rebase option because I didn't want to see the merge commit. But it's up to you. And as you can see, our repository went into rebase state. If we do not provide this option, then this would have been merging state a. The way we have to resolve the conflicts in one way or the other. We've already seen how we can resolve conflicts in gets off, merge as well as rebase in our earlier chapters. Same applies here too. So you can either decide to resolve the conflicts or you can use this command to skip the commit that is causing conflict. I'm going to do just that. But if you want to edit and resolve the conflicts, you already know how to do that. Rebase was successful. And when I do git log and not seeing the commit that we've just made in our local depository. That's because we had provided the options skip to skip the commit which is causing conflict ends. We're not seeing that come up. But if you notice the tracking branches pointing to the latest commit in remote repository, like so, I hope it makes sense. I'll see you next. 83. 1106 Using Stashing and Hard reset: Let's talk about significance of stashing. Let's say that we have a new committee and remote repository. For that. Let me edit the input dot TXT file and add one line of text. Like so. Commit the changes. And let's say that in my local enrollment, I'm going to edit the same file and add a line of text like so, save the file and close it. Now if I go to Git Bash and if I were to run the command git pull, notice that I haven't staged or committed those changes. I don't want to commit them because I'm still working on it. At the same time, I would like to pull all the changes from the remote repository to have my working directory updated. When I run this command, you'll see that Fetch has happened successfully, but merge didn't happen. It says your local changes to the following files would be overridden by merge. In for R dxdy, please commit your changes are stash them before you merge, and hence it has aborted the mod operation. Essentially get this confused as to what to do with those uncommitted changes. One solution to this is, and this is something that is not recommended. The command that I'm about to run can actually delete all the work you have done so far in your local machine. And that also includes the changes that we've just introduced in for art file. Obviously, this is not a recommended approach. But let me show you the command git reset. We've already used this command in the past. And then you're going to provide the option hard. And you would specify the remote. Let's see what this is going to do. If I type git log, you're going to see all the comments we have made locally or now gone for good. And that's what this command is very dangerous. But it served the purpose of being able to pull the changes from the remote repository. If you go here, you see that we only have these two files. Let us do git pull to pull in all the changes from the remote repository. And now our working directory is up-to-date. Basically our local depository as well as remote repository, or exactly in the same state. But this is not the recommended approach obviously. So let us try to recreate the same scenario once again. And let me walk you through how we need to deal with it. I don't want to commit these changes. But at the same time I'd like to get the updates from the remote repository. Let me go back to GitHub and edit this file one more time. Whatever. Let's try to do git pull now. And obviously, again, you're going to see much getting aborted. Like so. So what is the solution right now? The solution is git stash command. Basically, this command will temporarily store our local changes somewhere and we can retrieve them whenever we want. For now, since our local changes are causing trouble. To pull the changes from the remote repository, let me go ahead and stash them. As you can see, saved walking down a tree and index date, working progress on new feature. It is pointing to input.txt file. If you open up in full dot TXT file now, you're not going to see the changes that I've just introduced. Now we can go ahead and do git rebase. Go back to the working directory. You should be seeing all the remote changes. Now we can bring back all of the changes that I was previously working on with the command git stash, pop. Now obviously we'll have the complex can go back and open up input.txt file. You'll see that these are the changes that are coming from upstream. Upstream as in the remote repository. We can decide as to what changes we want to keep editing this file, like cell, close the file, stays the file. Git status. Now if I decide to commit my changes, I can do that. But able to pull the changes from remote repository without having to commit our existing changes. 84. 1201 Setting up everything for contributing Adding collaborator Setting credentials and making c: Okay, let us see how we can push our local changes or the local commits to the remote repository so that everybody else in the team can actually download those changes and use them all, start walking on top of them. Now in order to explain things better, let us clean things up and do everything from scratch as if somebody has just joined the team and willing to contribute to our repository. First things first, let me login as the owner of the repository. I've logged in as Sunda. This is Saunders GitHub account. And here's the owner of this public repository. I go to settings and then I'm going to add Mr. Luke as a collaborator. I'm expecting some contribution from Mr. Luke to this repository. As you can see, we have just added Mr. Luke as the collaborator. I also have deleted all the branches we had created earlier, except I left the main branch as is. So we currently have one branch. All of the branches were just deleted. Just so that we'll understand everything clean and clear. Now let's go to Luke's account. You can tell that this is Luke's account because this has the white theme. Here is the email that's under has received to accept the invitation to be a collaborator on that project. I'm going to do just that. The next thing that loop needs to do is to copy the HTTPS link and clone the project. For this purpose of actually created a new directory with the name get. And this is where we're going to experiment with things. Let me launch Git Bash here. And let's clone the project git clone. And then I'm going to paste the URL. This is going to clone the repository. One another thing we need to make sure is about the credentials. Let's type in the command git config list option so that we can see all the configurations. And as you can see, the username is my name and the email is something different, not Luke's. Now this is not a mandatory thing that you need to update these credentials. But what are the credentials that you give here is what would get reflected in concrete objects as well. So when you make local commits, these credentials would be recorded and same credentials would be seen even on the remote repository. Once after you push all those commits to the remote repository, it makes more sense to have Luke's credentials here because he is the one who is contributing to the repository. So let us go ahead and change these credentials. User.name. I'm going to give the same username has with the Luke's GitHub account. That is also change the e-mail to Luke's email. Like so. Now if you check the credentials, you can see that those who are updated. Now let us assume that Luke was given with the task to work on feature one. Guess what he's going to do? Well, he would create another branch and contribute all the changes related to feature one. Let's do that real quick. I'm going to do that from Visual Studio code. If you wish. You can do it from Git Bash as well. I'm going to open up the folder with VS Code. And maybe I'll just add one additional file. But before that, we need to create a branch. As you can see currently we are in main branch. Let me click on it and let me type in feature one. We don't have this branch yet. We don't have this branch even in the remote repository. Let me go ahead and choose this option to create this branch for us. Visual Studio Code has created this branch, and it has also switch to that branch. Now let me go ahead and add one file. Let's call it product dot TXT. Line one, feature one, something of that sort. I'm going to use the same text as the commit message. Let us enter the message and commit these changes in local feature one branch. Let us maybe also make one more comment line to like so when to copy it and have it as the message for this comet. Let's take a look at the graph. As you can see, we have the main branch here and feature branch, which is a couple of comments ahead of the main branch. Let us assume that Luke has done whatever he needs to do for feature one. He has tested all those changes locally. And now he's willing to contribute or push all these commits to the remote repository. How he's going to do that is something we'll talk next. 85. 1202 Creating a remote branch and pushing changes using Git Bash and VSCode Pushing to all branche: Currently we have feature one branch which was created locally, and we've even made bunch of comments in it. Now let's see how we can push all these commits to the remote repository. But before you do anything, this is very important. You need to make sure that you pull all the changes from the repository and rebase, whichever the brand that you want to merge your feature one branch into. You'd want to pull all the changes of that branch and rebuild your feature one branch to that branch. So that will have a linear commit history. And if you come across with any kind of conflicts, Kindly resolve them so that you do not have conflicts when you actually push all your changes or upload all your changes to the remote repository. We've already seen how this can be done in our previous chapter. In our case though, the main branch and the feature on branch haven't divulged. It doesn't make sense for me to actually rebase. Now let's see how we can push our changes to the remote repository. Let's first see how we can do that from Git Bash. Let me clear the screen. So let us first go into that directory. And I'm currently in feature one branch, as you can see here. But it doesn't really matter for the command that we're about to run. I'm going to say git push and get this saying the current branch feature one has no upstream branch. In other words, it is saying that we do not have feature one branch in the remote repository to push the current branch and set the remote as upstream. Use this particular command. So let me copy it and paste it here. So this command would essentially create one branch in the remote repository, pushing all the commits we have in this branch. Origin is the remote we're using. If you want to use some other remote, you can specify the name here. And this option will actually allow us to create the branch in the remote repository. This command will also create the track main branch and all local depository for feature one branch representing the feature one branch in the remote repository. Let's try running this command. Git has essentially compressed all the objects and has uploaded them to the remote repository. And this is the URI that it has used to push all our commits. In addition to that, it has also created a tracking branch for us. And it is also suggesting us to create so-called a pull request. By going to this URL. We're going to talk about pull requests in upcoming lectures. But for now let us go to GitHub repository and see if things got reflected over there. Let me refresh this page. And now you see two branches. And we can even switch to feature one branch like so. And you see for comets here, two of them belong to main branch. And then there are a couple of comments in feature one branch. Let us actually quickly make one more comment and see how we can push our changes using Visual Studio code. So let me just simply add one more line of code or text. Like so. I'm going to use the same text as the commit message. Let me save this file and commit our changes. So we've just made one more commit. This time I'm going to use Visual Studio Code to push our changes. You see this option, push. Since we have just one remote, which is the name origin. By default, this has pushed to that only remote which is available. If you had configure multiple remotes, then you'd get an option to choose that remote where you want to push all this changes into 1 second. Let's go back to get up. And if I refresh the page, you're going to see that new commit as well. There might be instances where you want to push changes belonging to multiple branches. In which case, you can use the option to push all the changes belonging to multiple branches. However, it is not recommended. It's always a good idea to handle one branch at a time. I also should mention that the first time you tried to push changes, you might actually get a prompt to login to your GitHub account. In my case, I didn't get that brown because I've already logged in previously. Let me show you what I mean. Let me open up Credential Manager on Windows by searching on the start menu. And if I go to Windows credentials, you'll see one for GitHub. And this has stored the credentials of Luke's account. That's because I had already logged in and Windows is able to store all those credentials so that I don't have to enter these credentials. Every time I tried to interact with the remote repository. In case if you see a 403 while running the command, then try removing these credentials and then try to run the command once again. So what you'll be prompted to login once again, login and you should be good to go. Let me actually remove it. And let me try pushing the changes. And as you can see, I got this prompt for authentication. Let me go to Luke's GitHub account, github.com, login slash device. Let me enter this code here. Control C and control V, continue. And arthritis. Let's entered the bus food device got authenticated. And of course, since we do not have anything to push, regard this message saying everything is up-to-date. But if you go back here, you're going to see this entry once again. I'll see you next. 86. 1203 Understanding Pull Request Raising a Pull Request: Okay, so far we have created local feature one branch and then made bunch of commits in it. And we've even pushed all those changes to the remote repository. And here are all those changes in the remote repository from GitHub account. Of course, since this is a public repository, anybody would be able to see all these changes. Now, loop cannot just try to emerge all these changes onto the main branch. There are certain practices to be followed. And those practices are in place to make sure what gets into the mainstream of evolution, which is the main branch, is clean code. So what we need to do next before we actually merge this feature one changes into the main branch, is actually to raise a pull request. Now what is a pull request? You can think of pull request as a review request. Essentially you're asking somebody, in other words, somebody in your team, other collaborators, or the repository owner to review all your changes before they can be merged into the mainstream of evolution, the main branch. And you might be wondering why this called a pull request. That word might make sense as we progress in this course. But for now you can think of it as you are making a request to pull all your feature one changes into the main branch. So let's see how we can raise a pull request. I'm currently inside the Luke's GitHub account. I want to go to this section, pull requests. Currently we do not have any product quiz. Let's create one by clicking on this button. New pull request. Here we're going to populate all the changes that we've done in feature one branch. How are we going to do that is by comparing our feature one branch with one of the other branches. In this case, we're going to compare feature one branch with the main branch. So the difference between the two are the changes that we've introduced in feature on branch. Here I'm choosing main branch as one of the branches. And the other branch would be feature one branch. So you're going to say list of changes introduced and feature one branch because these are the changes that were not present in main branch. And if you had multiple files involved in all these changes, then you'd be seeing all those changes here as well. But since all our genius went inside one single file, That's what you're seeing here. And it says showing one changed file. But anyway, here are all the list of commits, all the files that were actually modified with all these comments. Let's go ahead and create pull request. We can write a quick summary of what this pull request is all about. Introducing feature one, something of that sort. If you want, you can also leave a comment. And let's click on create pull request. Now we're actually getting this option that says merge pull requests. And if I click on one of these options, this is actually going to result in merging all the feature one changes into the main branch. However, this is not a good practice. Ideally, we want somebody to review or changes before we merge them into the mainstream of evolution. At this point in time, Luke is able to actually merge all these changes. There's a way to restrict this and we're going to talk about it next. 87. 1204 Understanding protected branches Applying branch protection rule Mandating Code Reviews: Let us see how we can restrict Luke from merging the code unless there is at least one review done by somebody else. For that, let me go to some dusk GitHub account. I'm going to go to the settings section of this repository. I got two branches section. And here I'm actually going to add so-called branch protection rules. When I add at least one branch prediction rule for a particular branch, that branch is called as a protected branch. All the branches where we do not have any branch prediction rules or non-protected branches. Just be aware of those terminologies. They will come in handy in a while. So let me click on this button that says Add Branch production rules. Here we can specify the branch pattern. In this case, I'm just simply going to say main. So all the branches that match with this pattern would have all these production rules applied. Of course, only the rules that we enabled here would be applied on the branches that match with that pattern. Now, we're going to talk about some of these rules in upcoming lectures. But for now, I would like to put a restriction that atlas one review should be done before merging changes into the main branch. So I'm going to enable this option that says required a pull request before merging. And the description of it says, when we enable this option, Hall commits must be made to a non-protected branch. So in this case we're targeting main branch. I'm going to apply this branch protection rule on main branch. So when enable this, nobody would be able to commit directly in the main branch. What they have to do is they have to first commit all the changes in non-protected branch. For example, feature one branch which is not protected, and then raise a pull request to merge all those changes into the main branch. That's what this option is saying. If this sounds confusing, I would request you to just go back and watch this video once again until you understand. And then we have this option that says required approvals. And here we get to choose number of approvals. We need our number of code review approvals we need before we can merge those changes under the main branch. Let's leave it to the default one. And let's click on Create. Once again, we're going to talk about how the other branch prediction rules in upcoming lectures. Let me quickly enter the password. And we have a branch prediction rule created for the main branch. Now let's go back to Luke's GitHub account. If I reload the page this time, luke would no longer be able to merge those changes. And look is now seeing review required. Now by default, any collaborator in the team or the repository owner can actually do view the changes. If you wanted to change that behavior, then we need to actually take one of those enterprise memberships of GitHub so that we get all that fine grain control. At the moment. We do not have control on that. 88. 1205 Reviewing and approving the changes Working on review comments and publishing new changes: So let's go to some there second, to review the changes done by Mr. Luke. This can also be account of some other collaborator in this repository. They can review it as well. And what they have to do to review all the changes done by Luke is that they're going to go into Pull Request section. Click on it. And then there'll be able to see this option, add your review. And here they can actually review all the changes. If they're not happy with any of these, then they can actually leave a comment saying, please update another line, something of that sort. And rather than choosing the option that pro, I'm going to set request changes, which means I'm not really happy with the code introduced. I want to look to bring these updates based on my comment. Then I want to review again. So let's click on Submit Review. On the Luke's account. He's going to say this changes or requested. He'll be able to see the review. Like so. Here's the comment made by cylinder. Please update another line. So what Luke is going to do is actually going to bring in all the changes based on the reviewer's comment. Something of this sort. Let's commit this change. We can push all those changes. Or alternatively, we can click this button that says sync changes. So this is going to push our changes. And if there are any changes to be pulled upward, be done as well. Let's go back to GitHub. And these changes should have been present and future one branch. And as you can see, we're able to see that new commit. Now we don't have to raise another poll request. The existing pool request would be populated automatically. Let's go back to senders account real quick. And Nelson lord is able to see an update saying that a new commit has been made. Typically look nice to send an email reminder or something. Or there might be some kind of a tool which would automatically send an email reminder to all the reviewers. So sender would view all the changes and he would review all the changes and assume that he's very happy with the changes, is going to protect them and saying something of that sort and is going to approve the changes like cell. Let's go back to Luke's account. Now look in bar from the March. We're going to talk about it Up next. 89. 1206 Exploring the merging options Understading Squashing commits Deleting remote branch from lo: Now that the review is done and changes are approved by one of the reviewers, Luke is good to go ahead and merge all these changes of feature one onto the main branch. If you take Organization license of GitHub, you'd get more fine-grained control. Last two can actually merge the pull requests at the moment with free version of the collaborators of your project would be able to merge the pull requests, including the individual who raise the pull requests. So all the in this case, Luke is actually trying to merge his own pull request. In real-time projects. This would be one of the team leads or some person who is authorized to do this job. Let's take a look at all the options we have here. We can create a merge commit. And as the name suggests, this is essentially going to create a new merge commit in the main branch. And it points to a couple of parent commits. One parent would be the last commit off main branch, the other parent KM, it would be the last commit off the feature branch. We've already discussed about merge commits. I don't have to reiterate once again. And not to mention enter commit history would be retained, which means you might as well be having all the spaghetti comet histories. If you do not want to have spaghetti commit history and don't want to create additional merge commit. Then you can go with the third option which says rebates and merge. So all the four commits from this branch, which is a feature branch, will be rebased and then add it to the base branch so that the commit history in the main branch would look more linear. We also have a third option which is squash and merge. And as the description of it says, the four commits from this branch will be combined into one commit in the base branch. This is as good as you're making a new commit in main branch with all the combined changes of feature one branch. This might be ideal solution if you have bunch of commits. And it makes sense to combine them together. In our case, we barely made any changes in each one of our commits, has just change of one single line of text. So maybe this option is ideal thing to do for us. Essentially, if you have multiple commits where you made minor changes, and if you think those can be combined as a single commit, we can go with this option. Not sure if you're able to recollect, but when we talked about interactive rebase, we had the option to squash some of the commits. Basically, when you're performing interactive rebase, you can list down all the commits that you want to squash or combine them together. So let's say you have ten commits in your feature branch. You can squash four of them or three of them or whatever that makes sense to you using interactive rebase. If you couldn't recollect, I would recommend you to watch the interaction with the best lecture on the same ones again. For now, let us go with this option, rebase and merge. In most cases it would either be merge commit or Rebus and merge depending on your requirements. I also should mention that since we had already rebased of feature branch to latest commit off main branch before we actually raise the pull request, we had resolved all the potential conflicts before actually raising the pull requests. And that's why at this point, you're not seeing any conflicts. But there might be those rare cases where somebody else in your team might have introduced changes in your main branch while you pull request is still active, which might actually create conflict. How you deal with those conflicts is something we'll talk about later. For now, let's go ahead and Rebus and merge. And as an assignment, you can also try out these two options. Pretty straightforward. Let's click on rebates and merge. Let's confirm. So pull request successfully merged and closed. And we're good to go ahead and delete this particular branch. We can delete it from GitHub, or we can also do the same from our local machine. Let me show you what I mean. Let me open Git Bash here. I'm currently inside the project. Let me now go ahead and delete the remote branch. And the command for that is git, push origin, name of the remote. And then you're going to use a colon followed by the name of the branch that you want to delete on the remote server. Feature one, in our case, I'm going to hit Enter. And this should delete the feature on branch in the remote repository. Let's go back. And as you can see, we now only have the main branch. And here are the list of commits in it, which now also includes all the comments were made in feature one. If I do git branch, you're still going to see the local branch. Let me get the name correct. We still have the local branch. Let's go ahead and delete it as well. Git branch, hyphen D, feature one. Okay, to switch to a different branch. And let's rerun the command. And the branch got deleted. Since the remote feature on branches deleted, even its corresponding tracking branch is no longer available. I'll see you next. 90. 1207 What Git Pull Actually Does: Every time you try to push your local changes to the remote repository, git will actually try to merge our local changes with the same branch in the remote repository. But it will do so only if it results in fast forward merge or else it will fail to push our changes and then way to work around it to get it done. I know this sounds confusing and that's why I've dedicated this video to talk about just that. And to explain things better. I'm actually going to do everything from scratch. Let me go to senders account and create a brand new depository. Let's give it some random name. It doesn't really matter. We're going to keep it temporarily anyway. And let's also add one of these files just so that we'll have one commit in the main branch once after we create this repository. Let me also add feature one branch are created. And then let's make a commit and feature one branch as well, maybe by editing the read me file. Line one, feature one. Let's call it line to. It doesn't really matter. Let's make the commit. Let's go to Settings and Add Mr. Luke as one of the collaborators. Alright, now let's go to Luke's account. So Luke has just received an invite to contribute to that project. Is going to view that invitation and accept the invitation. And then he's going to clone the project onto his local machine to start contributing. In one of the folders. I'm going to open up Git Bash. And let's do git clone this project. Let's go inside that folder. And if I do git branch, all you see that we have a remote Rachman branch of Maine as well as feature one, but we do not have the local branch off feature one. So in order to get it, Let's switch to feature one branch or checkout to feature one branch. So at now will have that local branch created. And currently we're in feature one branch. Let's actually do rest of the stuff from Visual Studio code. So let's open this project with VS Code. And let's say that I would like to make one comment in the new feature one branch. So we are currently in feature one branch. Let me maybe this time add one file, let's call it one dot dx, dy. I go to Source Control, give a message to the commit and commit our changes. Now imagine that somebody else in the team who is also working on the same branch, pushed few changes to the remote repository on the same branch to simulate that behavior. Let us go back to senders account and actually make a commit in feature one branch as if somebody has pushed the changes to this branch. Let me this term add another file, maybe two dot TXT. And let's commit our changes. Now basically both are local feature on branch and its corresponding remote branch or not diverged. Let us see what would happen if I tried to push our local changes to the remote repository. Git push, we can specify the remote and feature one branch. But if you just use this command, it is going to be the default behavior anyway. So let's push our changes and see what's going to happen. As you can see, we've got an error that says failed to push some refs to that repository and updates for rejected because the remote contents work that you do not have locally. So as I've said before, when we push our local changes kit will actually try to merge or local changes with the same branch in the remote repository. In this case, this is not resulting in a fast forward merge and that's what gets didn't push our changes. So what we can do here now is we can use the git pull command. And by default it will also try to perform merge of these both branches in our local enrollment. So let me try git pull to pull the changes. We could also do the same from Visual Studio code. If you wish. For example, I can say git pull from there or from here. Let's try to view the graph now. And as you can see, git has tried to perform merge feature one branch with our local teacher one branch. So this is essentially the merge commit. Now if you try to perform a push operation, it should succeed. And then we should be able to see this merge commit in the remote repository as well. But if you'd like to get rid of this merge commit, you already know what to do. Rebase is the answer. So let us try to rebase our current branch, which is the feature one branch on top of the recent change of the remote repository. Essentially I'm trying to rebase a local feature one branch with the remote tracking branch, which is essentially representing the remote feature one branch. So this is the commit that the tracking branches pointing to. I'm going to right-click on it. And then I'm going to choose this option rebase, current branch on this committee. And let's rebase as part of rebirth, as we've discussed before in one of our previous lecture. It will also get rid of all the merge commits. Because essentially we're rewriting all the commit history. And this sort of solves the problem of not having much commits. So now we have linear commit history. We're good to go and push our changes. This time. This is going to result in fast forward merge of both local feature on branch and the remote feature one branch. And so we shouldn't have any sort of problem or whatsoever. But generally speaking, you should be careful with rebase operation. And there are certain best practices to follow, which is what we're going to discuss in upcoming lectures. There is no problem as such in having much commit. You can also push your merge comment if you wish. And in fact, it is one of the popular choices because rebase might actually mess things up. Which is again, something we'll talk about in upcoming lectures. But for now, we're good to go and push our changes. And it is successful to go to the remote repository. Now, switch to feature one branch. Should be seeing all those comments, including the local commit that we had made earlier. I'll see you next. 91. 1208 Resolving conflicts on GitHub the right way Force pushing changes and it's consequences: Let us see how we can deal with conflicts when we're trying to merge feature one into the mainstream of evolution, the main branch. Currently I'm in feature one branch and as you can see, we have all those four commits from our previous lectures. What I'm going to do now is I'm going to raise a pull request for all the changes we've introduced in vitro, one branch raised pull request. Now I'm actually good to go and perform any of these operations. I can also perform repairs and much because no new comments were made in main branch and there's no way that it can cause conflicts. But what if after raising the pull request, somebody introduces new changes in main branch, which might be causing conflicts without feature one changes. To simulate that behavior. Let me go back to the main branch and edit this file. If you remember, in one of the comments in vitro and branch, we did update the ReadMe file. So if I update this file once again in main branch, this should give us a conflict. So let me click on this file and add some text like so, and commit the changes. Now let's go back to the pull request and see if we can now perform Freebase. And now you see a warning that says the branch has complex and those must be resolved. We can resolve conflicts here, but it's not a recommended approach. Long story short, this is going to complicate things a little bit. Basically, if you look at the history of chametz, it's going to confuse you. There's a better way to handle this. And that's what I'm going to show you now in our local machine as him that this is looks computer. First of all, we're going to bring in all the changes in the main branch. So let me switch to main branch and pulled up new commit. Now let's try to rebase our feature one branch on top of this new commit. This is a standard procedure we had followed in one of our previous lectures. What are you basing someone to switch back to feature one? Right-click on this commit and choose this option that says rebase current branch on this committee. This should give us conflicts. And as expected, we do have conflicts. That mean dismiss it. So let us resolve those conflicts. Maybe this time I would like to accept both the changes. Save the file, and let me state it and click on Commit. This is going to essentially create a new commit with all the result conflicts. Let us enter some message. I'd like to keep it as it is. Once you close it. This should rebase which one branch on top of that new commit. Like so. So now all the commits off which on branch or seen on top of this commit. Now let us try to push all this changes to the remote repository and see what's going to happen. Let me clear the screen. We could also do the same from Visual Studio Code. Let me type in the command git push and see what's going to happen. 1 second we got this hetero saying, fail to push some references to the remote repository. That's because with rebase, enter commit history got rewritten and it doesn't match with the commit history we have in the remote repository. Now get good thing that our local feature one branch and its corresponding feature one branch in the remote repository, or both diverged. And so it's not allowing us to push our changes. So how do we push our changes now to the remote repository? Well, we can use the option force. So this time with git push and when to provide the option force. Now what is this going to do? The force flag will make the remote repositories branch match with your local branch. And it will delete all the upstream changes that might have come since you last bullet. Which also means that if there are multiple people working on the same branch and if somebody had contributed their changes to the same branch, all the work would be lost, which is sometimes not desirable. So there are instances where you shouldn't be using the force option. We're going to talk about all that and best practices in upcoming lectures. But for now, this is going to do the job for us. And if you go back to the remote repository, you notice that we can now perform rebase and merge or even other two options. Let's take a look at the commit history real quick. To go to feature one branch. Take a look at list of commits. So we have all these comments made on feature one branch stacked on top of the comments of main branch. We can now go ahead and perform rebates and merge. We can also dissolve the complex and GitHub, but it's going to do weird things like Robeson, the main branch on top of which one branch to get things done. And that might create a lot of confusion. But this is often the common practice followed to resolve the conflict. Now it doesn't make sense to have the branch around. So I can delete it. Hope it makes sense. I'll see you next. 92. 1209 Divide and Conqr Strategy: Let us see how we can handle the negative consequences of using force option. When you use the push command. I mentioned that when you use the force option, the commit history on the remote server will be forcefully overwritten with your own local history. Now there are a couple of consequences with that. Number one, we might be having multiple developers working on the same branch and we might risk losing all the commits done by them that came after your last poll. And secondly, most importantly, when you do Rebus and then force, push your changes, it might actually create a mess because everybody else in the team might have downloaded the project and might've checked out to that branch. Essentially, when you rebase and pause push your changes will not only were reading the commit history, but also their hash codes. And all the team members who might have downloaded the project and Chet dot to that branch might have a different set of common history compared to what's there in the remote repository. That's going to create a lot of mess. So in order to prevent this, we have a strategy called divide and conquer. Let me explain what I mean. Let's say that this is the main branch and this is the feature branch in the remote repository. Now let us assume that couple of developers are willing to contribute to this branch. Instead of they're both contributing to this branch. We're going to now have couple of sub-branches and each would be owned by individual developer. Both this dollar per would contribute their own set of changes on their own sub-branches. And since they're walking on their own branch, changes done on one branch will not have any impact on the other branch. For example, one of the developers may want to rebase and force commit all those changes to their own branch. And it will not have any kind of impact on the other branch owned by the developer. And once after one of the developers is done with whatever they have to do, they can then merge all the changes onto the feature one branch. And then the other dollar par would rebase their branch on top of feature one branch and then eventually merge their changes as well. And if there are any changes that either of the dollar plus might've missed out, they can create another branch and bringing all those changes. And then of course, merge those changes in feature one branch. This is called divide and conquer strategy. And this might prevent the side effects that might come when you force push your changes. However, there might be instances where this approach may not be feasible. In which case we have an alternate to, and that's what we're going to talk about next. But maybe you can take this as an assignment. Try to create couple of sub-branches from the feature one branch, and try to follow divide and conquer approach. 93. 1210 Resolving Conflicts by merging main in to feature branch: Okay, let us see how we can deal with conflicts by merging the branches without having to use the force option, or by following the divide and conquer approach. For that, let us first try to create another conflict. Since we have already deleted feature one branch, let us create a new branch to introduce new conflicts. Let's call it new feature. Whatever. I'm going to create this branch. And let me edit one of these files. Let's say I would like to edit one dot TXT file. And I'm simply going to add the name of the branch like cell. Commit the changes. Let me switch back to main branch. And let's try to edit the same file once again, so that we'll have conflict. Let's just say main and commit the changes. Now let's go to pull requests and try to raise a new pull request. So we're comparing main branch with the new feature branch. And here are the changes. Let me go ahead and create the pull request. As you can see, we're getting a message that says this branch has complex that must be resolved. And we also have the option to resolve conflicts. How good that would allow us to resolve the conflicts is by actually merging the main branch into the feature branch. Now this might actually surprise you, but it actually works. Let me show you what I mean. Let me click on resolve conflicts. This is as though we were in merging state where conflicts needs to be resolved. And we can resolve the conflicts just as we had dissolved them in our local machine when we're trying to merge branches. So essentially in this case, GitHub is trying to merge main branch onto the new feature branch. And that would essentially bringing all the changes of main branch or all the comments of main branch onto the feature branch. Like to keep both the changes. And I'm going to click on this button that says Mark. As result. We're going to come at the merge. This is going to create a merge commit, and that will point to a couple of parent commits. The last comment of the main branch and the last commit off the new feature branch. Pretty similar to what we've done in our local machine when we're trying to resolve the conflicts. While margin. Here you can see that we have just merged main into the new feature branch. And this has solved the problem. To go back to the repository, commits in main branch would remain as this. Let me show you. But whereas if you go to the new feature branch, it has all the commits into it in the comments that were made and new feature branch and also the merge commit. If you go inside that, you're going to see that it has couple of parents. One parent is the last commit of the main branch, and the other is the new comment that we've just made in the feature branch. So this merge commit snapshot would have changes introduced in both these branches. And that's why we're able to see all the commits belonging to both the branches. Now I'm not sure if this is actually confusing you, but this is actually pretty straight forward. If you do not understand this, then that's perfectly all right. We've already discussed couple of ways to resolve the conflicts. In last couple of lectures. You can go with that approach or you can also follow this approach. You can also do the same even in your local depository. Just check out the project and try to merge main branch on your feature one branch, resolve the conflicts so that you'll have similar commit history in your local machine. And then you're going to push all these commits to the remote repository with the standard push command. Let's go back to the pull request. Now we no longer have the conflicts. This branch has no conflicts with the base branch. And we're good to go ahead and perform merge. You cannot perform rebase though. You cannot perform rebase because as you already know, rebase is going to rewrite the commit history and even get rid off the merge commits. In this case, it doesn't make sense to do that. That sounds confusing. Then just remember that it cannot perform rebase. In this case. If you try to perform rebase, it says this branch cannot be rebased due to complex. The message is not very clear actually, but I hope you got the point. But we can merge the changes and commit them merge. We can now get rid off the new feature branch. And that's the alternative way to resolve the complex. I'll see you next. 94. 1301 What is Forking and why forking: Let's talk about for king in GitHub and its significance. Imagine that we have an open-source project with the name open app in GitHub repository. And say that this is owned by Mr. Sunda. Now when I say this is the open source project, you can expect hundreds or even thousands of developers across the globe who are willing to contribute to this project. Now imagine the amount of work that's been done needs to do to manage the collaborators. If cylinder what to manage hundreds or thousands of collaborators, it becomes a job on its own. For example, every time somebody wants to contribute, whether it is a small contribution or a large contribution, there still needs to add them as collaborator. Secondly, if sundries using the free version of GitHub, then essentially every collaborator, we'll have the privilege to merge their code onto the main branch. Now imagine some beginner dollar per who's just getting started with programming. Deliver some code and modulus those changes on the main branch without doing adequate testing. Obviously, that's going to create a lot of mess. So we need a solution to this problem. Well, the solution is forking. So what exactly is forking? Imagine that we have Mr. Luke wants to contribute to this project and he's not added as a collaborator on this project. So what Luke is going to do is with just a click of a button, has gone to folk this repository on his own GitHub account. You can think of working as clone. But instead of cloning it on the local machine, it's going to happen on the GitHub salvo on Luke's account. In this case, Luke and rename this project to whatever the name of his choice, or he can also keep the same name. It doesn't really matter. As a standard naming convention. Default repository is referred as origin and the original repository is referred as upstream. You can of course call them with any name of your choice. But these are the typical naming conventions we follow as developers. So whenever I say origin, I'm referring to the forked repository. Whenever I say upstream, I'm referring to the original repository from where we have four. Now look, we'll make a clone office forked repository, even in his local machine. He will then introduce all the changes that it needs to introduce and it's going to push all these changes on the forked repository. Meanwhile, if there are any new updates on the original depository, look and actually pulling all this changes onto his local depository and push all those changes or new commits to his forked repository. That way, default repository will stay up to date, but the newly introduced changes in the original depository ones after Luca is done with what are the changes he wants to introduce. And of course, after adequate testing is going to raise a pull request, asking some there to accept all these changes and merge those changes in the main branch of the original repository. So this vessel in there doesn't need to write access to look to start contributing. This approach of contributing to a project by forking the repository is not only good to the owner of the repository, but also the dollar plus one to contribute to the project. Here are some of the vantage is for developers for using forking. Instead of directly contributing to the original repository. Walking allows anyone to contribute to a project without having the right access. Because they can just create a fork of a project, introduce all the changes, test them, and then raise pull request. They can freely experiment with changes without affecting the original project. In some instances, there could be multiple people who collectively want to contribute to a particular project. In which case, it's always better to fork the original depository, deleted all the changes, do integration testing. And once they are done, they can raise pull request, asking the original deposit to the owner to pull in all the changes and merge those changes on the main branch. Walking allows you to use someone else project as a starting point for your own idea. A lot of commercial software or applications were originally initiated with an open-source project. They just work on all the existing open source projects and introduce changes on top of that and sell it to their customers with the commercial license. And lastly, you don't have to wait for right access. Imagine you're writing an email to the posterior owner asking for right axis, and then you wait forever for response. Well, with forking, you can straight up to contribute to the project and race pull requests without having to have the right access to the original depository. We're going to see all this inaction and more in upcoming lectures. I'll see you next. 95. 1302 Forking a public repository and cloning it in our local machine: Okay, let us see how we can fork a repository to start contributing. Now imagine that this is Luke's computer and he's willing to contribute to one of the open-source projects available online. So let me go to Luke's GitHub account. And here it is. And assume that this is the project that Luke is willing to contribute to. This project is actually owned by Mr. cylinder and look, does not have the right access to this project or he's not added as one of the collaborators for this project. This time, since loop cannot directly contribute to this project, what is going to do is, is actually going to create a fork of this project. So here you see an option that says ****, you can add the click here. I'll click on the drop-down menu. And you see an option that says Create a New Fork. Hey, the way you'd be taken to this page where you will be asked to give a name for your repository. You can keep the same name as with the original depository, or you can rename it to something else. For example, maybe looks, app or whatever, doesn't matter. Optionally, you can also provide description and click on this button that says create fork. So essentially we have created a clone of the original project on Luke's GitHub account. And Luke can now do everything what he would otherwise do on his own public repository. And the fact that this is actually a clone or a forked version of some other repository. You're going to see all the commit history is branches. Everything is as is, except for a forked repository. You're going to see this icon signifying that this is a forked repository. And also this text that says forked from the cop 1996 slash my public cap, which is the original depository. Solute, can now start contributing to this project. He can even add additional collaborators. If Luke is having a team of developers who might be wanting to contribute to this project. You can add collaborators or branch protection rules. Everything what one can do with a public repository. You can do the same even with the forked repository. Except of course you're going to see a difference of the original deposited here. This reference will come in handy at later stage and we're going to talk about it in upcoming lectures. For now. Let us try to clone this project. Let's copy the HTTPS URL. Inside looks computer has just simply going to clone his own repository. Git clone and paste the URL. Let me go into that directory cd. And let me type in the command git remote hyphen v stands for verbose. As you can see, it has already added one remote with the name origin, and it is pointing to the forked repository. So when I say origin, I'm actually referring to the forked repository. And down the line would also be required to add another remote, which is upstream remote. And that points to the original repository will continue from next one. 96. 1303 Contributing the necessary changes: Now, what are the changes that Luke wants to contribute to this project? Is going to bring in all those changes locally, test them, and then push all those changes to his own forked repository in order to simulate that behavior that has made bunch of commits. And of course, as a good practice, we're going to create a new branch. And that's where we're going to make our commits. That's what I've been preaching all throughout this course. We would never want to make commerce statically on the main branch, but rather we'll create a new branch and make hollow contribution. So let's open this with Visual Studio code real quick and create a new branch. Let's call it feature ten. Maybe. Create a new branch. And I'm just simply going to add a couple of files. One dot TXT, for instance, go to Source Control, created one dot TXT. Commit the changes. And let me make one more committed. Maybe two dot dx, dy, whatever. Just wanted to make sure that we see couple of comments. And this feature branch has the word introducing our changes. We have feature one branch and we have made a couple of comments in it. You can see it in this graph here, as you can see, the feature one branches, couple of comments ahead. The main branch. Now what if, while I'm still working on this feature, we have bunch of new updates on the upstream repository or the original repository. How are we going to get all those updates in our local machine as well as forked repository. That's what we're going to talk about next. 97. 1304 Syncing the Forked repo with original one and updating local: Okay, let us see how we can keep our local depository as well as the forked repository in-sync are up to date with the original depository. In order to simulate the behavior where we have some new updates in the original deposit today. Let me actually go to senders account. Who's the owner of this repository. And let me make a commit in the main branch, maybe by just adding one file. Let's give it some random name. Something of that sort. Apple dot TXT. Sorry for the funny names. I just wanted to keep things simple. Let's create this file. So we have some new changes in the original branch. Now there are multiple ways to keep our forked repository in sync with the original repository. The one that I'm going to talk about now is the easiest approach off all. So let's now go to Luke's GitHub account. Let's refresh the page. So this is the forked repository. Here you see a message that says this branch is one commit behind the cop main, which is the original depository. And here you also see an option to sink fork. If you click on it. You'll see the option to update the branch and do take a note that we're currently in the main branch. So essentially the main branch of the forked repository is compared with the main branch of the original depository. And that's how GitHub is telling us that we are actually one commit behind the main branch of the original depository. When you click on sync fork, you'll see the option to update the branch, click on it. So this would fetch and merge our changes. And as you can see, we have that new file over here. Now, when it did fetch and merge, it is like pool operation. And that's going to result in fast forward merge. And there's no way that we can get conflicts here because we're following good practices of not making our contributions in the main branch. We created a feature branch and that's where we're bringing in all the changes were not touching the main branch. So when we think both the repositories, there's no way we're going to see any kind of conflicts in case if you're not following good practices and you make comments in your main branch, you might as well be seeing conflicts and then you have to deal with those conflicts. Once you have it in the remote repository, all you have to do is to pull these changes even in your local repository. Let's do that real quick. And as you can see, we got the updates from default repository. 98. 1305 Syncing the Forked repo with original from local repo: Let us take a look at one another way to keep the forked repository and the local depository up-to-date with the original depository. For that, let us quickly make one more comment. In the original depository, which is on bus window. Just to simulate the behavior of having new updates in the main branch. I'm going to add a new file, something of that sort. Once again, sorry for the funny names. Come with the new file. This time, what we're going to do is we're going to actually pull all those changes into a local repository and then push them to our forked repository. Let's see how we can do that. Let's do it from Git Bash. You can also do the same from Visual Studio code if you wish. First things first, we need to pull in the changes from the original Depository. How are we going to do that? If I say git pull, this would actually pull from the origin remote, which is the forked repository. But we actually want to pull it from the original depository. How are we going to do that? First of all, we need to add that remote. If I say git remote hyphen v, You see that we have origin demote and is pointing to the forked repository. Let us now add another remote, git, remote add. And I'm going to name it as upstream. As I've mentioned before. We're going to call the original depository as upstream. And here we're going to provide the URL of the original depository. So let me just copy this here. I can also use this link if I wish. This command has just added the upstream repository. If I run this command once again, you see that we now have couple of remarks. Now let us try to pull in the changes from the upstream repository. Git pull then upstream main. So we want to keep our main branch up to date. This has pulled in all the changes. This is the file that we've just created. You can see that in the Visual Studio Code as well. However, these changes are not yet available in our forked repository or the origin server. So guess what we need to do next. Git push. And this should push this new commits to the forked repository. If you go to Luke's account now and reload the page, you're going to see those updates. 99. 1306 Pushing our changes to the forked repo: Okay, Let us assume that Luke is done with all the feature ten changes. And now he's willing to propose all these changes to sender, who's the owner of the original depository or the upstream repository. But before Luke even consider doing that, he need to make sure that it has got all the updates, all the latest updates from the upstream repository, and makes sure his forked repository as well as the local depository, are up-to-date with it. We've already seen how it can be done in last couple of lectures. The second thing that loop needs to make sure is to actually read this as feature branch on top of the main branch. So let's do that real quick. I'm going to switch to feature ten branch. I'm going to right-click on the latest commit off the main branch. And then I'm going to choose this option that says rebased current branch on this. With this, we get rid off any possible conflicts that might occur. If you come across with any kind of conflicts, you already knew how to deal with that. Once you're done with that, you're actually going to push all these changes to the remote repository or to the forked repository or the origin. So let's push all this changes. We get a prompt that says the branch feature Dan has no remote branch. Would you like to publish this branch? I say, okay, I want to choose the origin acid mode. That's what I want to publish or push our changes to. It is successful. That has go to Luke's account and see if things got reflected. And sure enough, you're now seeing let me reload the page. You're now seeing this new branch. Next we're going to see how we can raise pull request to propose our changes to master cylinder. I'll see you next. 100. 1307 Raising the pull request and merging the changes in upstream repository: Let us see how Luke can propose this changes to surrender by raising a pull request. There are multiple ways to do so. Here you already see an option to compare and raise the pull request. You can either click here or you can choose the feature branch in the list. Then click on the drop-down menu under contribute, and you see the same option to open a pull request. Alternatively, you can also go to pull requests section and raise a new pull request. Whichever way you follow, you're going to see the screen where we need to compare the branches to see the difference of the two. Here we're going to compare the main branch off upstream repository with the feature branch of the forked repository. The repository here is referring to the upstream repository. And here we have chosen the main branch. The head repository here is pointing to the forked repository. And here we need to choose the feature branch. So this is going to show a summary of all the changes we have just introduced in the feature branch. We can now just go ahead and create the pull request. The process is pretty much similar to the pull request process we had talked earlier. So once after pull request is raised, they can actually review the changes. He can either accept or deny or ask you to work on bunch of comments, etc. Let's now go to cinders dashboard. Reload the main repository. Here is going to see the pull request. Let's click on it. We've already talked about a variety of things we can do here. For example, I can just say rebates and merge. But before that, since we have a branch prediction rule, to do at least one review, let us quickly review the changes and say that I'm happy with all the changes. I'm going to approve and submit the review. Now I can actually go ahead and choose any of these options. Maybe I'd like to go with merge. Confirm merge. And now all of this feature related changes are merged into the main branch. So you see all those files here, one dot TXT and two dot TXT. And we're inside the main branch. Throughout this entire process, Luke was never added as collaborator in the original depository or the upstream repository. Yet he was able to contribute to this project. I hope it makes sense. I'll see you next. 101. 1308 Exploring Existing Public Project: In this video, we're going to explore one of the existing projects available on GitHub and see if we can make sense out of it based on what you've learned in this chapter. If you have any project in mind that you already know, then you can search it up over here. Are you can go to explore, to explore some of the public projects. You can also take a look at projects based on a particular topic. Here you're going to see a list of topics arranged in alphabetical order. Here are list of popular topics. Let's click on maybe react. Let's randomly open up on all the projects here. An x dot js. I'm just simply going to pick something random. Maybe this one iconic framework. The first thing you're going to notice once you visit the project page is the read me file. Readme file would typically constitute information about the software, how you can install it in case if you want to get started as contributor for this project, what are all the steps involved in that? To get started as contributor, you will find projects which are plants and bunch of such information in the ReadMe file. So this is probably the starting point. If you want to get started with a particular project. Once you go through the ReadMe file, you can actually get started with the contribution. But let's explore the Pull Request section here. As you can see currently it has about 33 actor poor requests which are yet to be merged, are reviewed. You basically are going to see a couple of types of requests. The first one is the one that we've talked in our previous lectures. The second one is something that we haven't yet talked. It is called Draft pull requests. You can say that a particular pull request is a draft for request. By looking at this icon, if it is grayed out, then it is a draft pull requests. You might be wondering what is a draft for requests. We're going to talk about it in upcoming lectures. But basically, if you have any changes which are just proposed changes to have the discussion on or to take feedback, but are not really intended to be merged. Then you can raise a draft for requests. Just initiate that discussion. Everybody else can actually take a look at your code changes and put some comments on it. And based on that, you will decide whether you want to proceed with that or not. You also notice these so-called labels to the right of each pull requests title. Again, this is something we'll touch on in upcoming lectures. But labels would essentially allow you to classify the poll requests. In other words, it would help you categorize the poor requests. For example, if I click on this label, you're going to see all the pull requests that are corresponding to that particular label. As the owner of the repository, if I would like to take a look at list of pull requests that corresponds to a particular label. I can do that. You might be seeing bunch of other things here which we haven't yet talked about. We might explore them in upcoming lectures. But I guess you have raised to a stage where you can learn things on your own. In fact, that's the goal of this course to make you stand on your own. I really cannot teach everything that is out there. My job is to make you feel comfortable with the technology. And I think so far we have reached that stage. It is now up to you will have to explore, go beyond, and do something to expand those skills further. One of the best ways to do that is basically to actually contribute one of these projects. For example, if you're learning React or Python or whatever, just take a look at bunch of projects that are here related to that particular topic and start contributing. Every project must be having some instructions on how you get started as contributor. You can go through that and get started with contribution. So these are all the pull requests raised by people like you and me. And you can see that this project has been forked for over 13 thousand times. By the time of this recording. Let's take a look at list of issues. So there are about 554 issues currently. If you want to report a bug or suggest a new feature, you can do that as well by clicking on new issue. You can add the report, a bug, or request for a feature. You can go through the documentation, et cetera. This layout is actually customized for this project. You might see a slightly different layout depending on the project that you're viewing. For example, let's say that I've used their software and I found a bug, and then I wanted to report that bug. So I can certainly click on this. And they have designed a format to report the bug. First of all, they wanted to make sure that I read the contributing guidelines. Once I do that, I can click on this checkbox, their code of conduct, etc. The Washington, which bug is deciding? What is the current behavior, what is the expected behavior? Clear steps to reproduce, and bunch of other information to ultimately help somebody who wanted to fix this bug get all the information they need to fix the bug. Let's go back to issues. So you can take a look at these issues. If you think you can fix one of these, you already know what to do. You just have to fork the project, clone the project, your local machine, fix the bug, push those changes to the forked repository, and then raise the pull requests. Like I said before, take this as a task and actually contribute to an odd, they're valuable projects on GitHub. Once you get your pull requests merged or approved by the code owners, it's going to give you a lot of satisfaction and it will give you some sense of accomplishment. Once you see that happening. It might take some time for the entire process to complete. But I highly recommend you to do that. And that way you're putting everything together. What you've learned in this course so far. In the rest of the course, we're going to talk about all the missing pieces in these technologies. But like I said before, I think we've reached a stage where you are on your own and you've learned all the essential topics of Git and GitHub. I wish you good luck, but we're not done with the course yet. We've got a lot of other topics to discuss as well. So yeah, take it up as a task and contribute to an off day valuable projects. I'll see you next. 102. 1401 Branching Strategy Explained: Let's talk about the strategy for branching. We have the master or the main branch. And generally speaking, whatever goes inside the master or the main branch should be production ready. In other words, you need to assume that water gets inside the master or the main branch is something that your customer will start using. In fact, you might as well be having some sort of an automation in place where it will constantly pick the code from the master or the main branch, create an artifact, and deploy them on the production enrollment so that your customers will now receive all those new updates or features. As an example, imagine that you're developing an operating system like Windows. The moment to deliver something on the master or the main branch, your customers might see a pop-up saying that there is a new service pack available to install. They will then install that service pack to get all the latest features or bug fixes. The fact that this is production ready code means that you should be careful as to what goes inside the master or the main branch. What goes inside the master or main branch should be absolutely tested. Quality assured code that you really cannot risk having any kind of bugs. So obviously for that reasons, he cannot make the master or the main branch to be available for developers to contribute their code. If you do so, then every time somebody merges the code in the main branch for each and every feature, your customers are going to get those updates as well, which are of course not So tested. And obviously it's not a good practice. So what we're going to have is we're going to have another branch called the development branch. And this is going to be the most active branch where all the developers would contribute to. In fact, the moment we create a GitHub repository, we're going to make development branch as the default branch so that whenever somebody clones the code into their local machine, we're going to see the development branch as a default branch. In fact, we're not going to let anybody contribute to the master or the main branch. Instead, we would only open the development branch or contribution. Only particular set of people will have the permissions on the master or the main branch to actually merge the quality tested code. And even in development, every time somebody delivers a code are raises a pull request. We might as well be having some sort of automation here as well to sort of check the quality of the code. For example, checking to see if there are any security vulnerabilities, are trying to perform some scan, check for any programmatic errors, etc. to make sure that the code still adheres to the quality standards of the organization every time somebody contributes to this branch. Now imagine that there are bunch of features delivered on the development branch. And it is at this point in time, we realized that we can actually release all this fetus to the end-user. Now we could actually merge all those changes with all the latest features on the master branch. So do your customers will start using. But we have one more step to take care. We're actually going to have yet another branch called the release branch. And that's what we're going to merge all the latest development from the development branch. The release branch sits in-between the master main branch and the development branch. It sort of like a pre-production enrollment where we might actually do some automation testing to make sure that all the features are functioning as expected. Once after testing is done, everything is called the assured. We will then merge all the changes from Release branch to the actual master branch. And the code would now become the official version of software that the customers will use. Well, I'm sure that all this might sound confusing. So let me take a real-time example and walk you through this diagram once again. So I do understand better and we'll do that next. 103. 1402 Branching Strategy with Realtime Scenario: Okay, Let us understand all this with a quick real-time example. So imagine that we have bunch of developers who contributed their code, whole bunch of features to the development branch. Or it might be the case that your project has been forked by bunch of people. And they raised pull requests which eventually got merged into the development branch. But ultimately we have bunch of features in a development branch. And it is at this point in time we have realized that we can actually deliver this to the customer as a new release. Now we could just merge all these changes sound to the release branch. But before that, we're actually going to create one more branch, the version one dot or at all, with an assumption that this is the very first version of the software we're releasing. The kind of format we're following for worsening the software is so-called the semantic versioning. We're going to talk about it in upcoming lectures. But for now this is the version. And we're going to name our branch with that version number. You know, the purpose of creating this branch in just a bit. So once we create a branch called portion one dot o dot o from the development branch. We will then merge all those changes on the release branch. And this is where all the testing happens and any additional things that you want to do, you can do it over here before actually merging those changes into the master branch, which should be production ready code. So eventually it ends up in the master or the main branch as well. The good thing about this strategy is that while you're busy releasing the software and testing the software thoroughly, before actually getting them onto the production and Rome and other developers can actually continue working on that task and dilute the features in the development branch. Now imagine that the customer has reported a bug. Maybe a software would allow the customer to report a bug the moment defined it. So assume that worldview costumer found the bug, he reported it. And you realize that it is actually very serious bug which needs to be fixed on priority. So what you need to do is you're going to create a branch from this version branch. And you're going to increment the value by one. Again, this is called semantic versioning. We're going to talk about it. But essentially you're going to create a branch out of the previous version. And this is where you're going to fix the bug. Once you fix the bug, you're going to test all the changes. And then you're going to merge all those changes in the development branch as well as on the release branch and eventually on the master or the main branch as well. So you'll customer will have the fixed for the bug report that I'm actually going to demonstrate all this on GitHub pretty soon so that you'll have a better clarity as to what exactly is happening here. I'll see you next. 104. 1403 Semantic Versioning Explained: Let's talk about semantic versioning. Semantic versioning is a standard practice followed to worship in a particular software release or a library or an API. And here is the format of semantic versioning. The first part is the major version. The second part is the minor version, and the third part is called a patch. The way the semantic versioning works in K, software. Software is slightly different compared to the way it works in case of an API. Let's first talk about in case of a software, something like a video editor or an operating system, et cetera. So whenever you have any significant changes are a huge chunk of features. Or maybe you have deleted some of the existing features are significantly modified, existing features, then you might want to consider incrementing the major version. When you do that, you're going to reset the values of both minor as well as patch back to 0. Or if you have just a couple of features delivered and they're not very significant, then you can consider incrementing the minor version number. And if you have any bug fixes or hotfixes on top of this version, then you can consider incrementing the patch version as and when you introduce new hotfixes, you're going to keep incrementing the patch number like so. Now let us say that you have worked on couple of more features and they are just minor changes. You can once again increment the minor version number, but then you have to reset the value of patch back to 0. This is how the semantic versioning works. And as I mentioned before, the way this works in case of an API, is slightly different of an API whenever you increment the value of the major version would mean that you have introduced significant changes that would no longer be backward compatible. For example, maybe you have removed certain features or modified significantly some of the existing features. What that means is all the projects that we're using previous version of your library would have to consider changing their code before they can take the latest version of your library. That's what it means when you increment the major version. However, incrementing the minor version would signify that the new features or functionality has been added and doesn't require anybody to modify the code to make their code compatible with your library. The patches similar to the patch we had talked earlier. If we're incrementing it, that means you have provided a bug fix or a hot fix. So that's how semantic versioning works. I'll see you next. 105. 1404 Understanding Git Tags: Let's talk about tags and get. Etag is simply a difference that points to a specific point in the good history. In other words, attack would just simply point to a specific commit. Now this might sound like a branch. Even branch does point to a specific commit, and even tag does point to a specific combat. But the difference between the two is branch would get updated every time we make a new commit in the branch. And branch would point to that latest commit, whereas tag would remain constant. If we create a tag pointing to a particular commit, it will remain like that forever unless we do something with that tag explicitly. Now, what's the advantage of creating a tag? Why do we want to create a reference to a particular commit and keep it constant? Let's take a look. So this is from our previous example, 1 second, assume that we have launched a new software and eventually we have are changes in the master branch. It is at this point in time we're going to create a tag, giving it the version number of the software has its name. Since we assume that this is a very first release off or software, we're going to worsen it as one dot o dot o. And this tag points to this particular commit, the master or the main branch. Now assume that we have provided a hot fix. And once again, we have delivered that fixed in the master branch. We're going to create yet another tag, giving it some motion number. So since this is a bug fix or a hot fix, we just incremented the patch number by one. So essentially we are following semantic versioning here and this tag points or have the reference of the commit in the master branch with that fix. But what's the point of having all these tags? Well, one other use cases is, let's say that I wanted to create an artifact based off a specific version. So maybe I can run a command saying that I want to create an artifact for version one dot o dot o. Guess what? I can run the command specifying this tag. And the tool would create the artifact for me, which can then be deployed onto the production enrollment, etc. Or maybe I can put it in the release notes for customers to download and use. We cannot use branch in this case because branch would get updated every once a while. The moment we make a new commit in the branch, tags would come in handy in such situation. Next, we're going to take a look at all this in action so that you will have complete picture as to what exactly is happening and how's it going to work. I'll see you next. 106. 1405 Braching Workflow in Action: Okay, now let us see everything in action and I hope you're ready for this. Let us first go ahead and create a new repository. Let us call it maybe super audio. Maybe we're creating an audio editing tool whatsoever. And maybe I'd like to add the read me file as well. If you wish, you can actually go to settings and change the default branch name of main to something else if you wish. Maybe we can change this to master. It's not mandatory. But I'm doing it anyway. I'm going to create the repository. As you can see, we have the master branch. And this is going to be the production wrench, meaning that whatever goes inside the master branch would go into production enrollment. Next, let's go ahead and create the other two branches. One is going to be the pre production branch, and we'll enter name it as release. And another branch is for development. Let's call it develop. This branch would be having the latest of the latest code from all the contributors are collaborate to us. Let us now go to settings and make the develop branch as a default branch. Just so that if somebody were to clone the project, they're going to see the develop branch as a default one where they can contribute. So we're going to change this branch from master to develop and click on Update. Now if I go back, you're going to see olive branch chosen already because that's going to be the default branch now. Now, in order to simulate the behavior, to have bunch of features in place in the development branch. I'm simply going to add a couple of files. But you need to make an assumption that maybe we have done some feature related changes and contributed to this branch. It might be the case that somebody else for the project and raise pull requests on this particular branch. So whoever folks this project, it is expected, the race pull requests on the dollar branch. They do not have any kind of permission or we do not expect anybody to make contributions to the release branch, hard the main branch or the master branch. So let us go ahead and create a couple of files. Create a new file, Let's call it feature one dot TXT. Just to keep things simple, we're going to create yet another file. Create a new file feature to dot TXT for instance, and commit the code. So we have bunch of commits here. The first one was the read me file, and the other two are for the features. Now what's the next thing to do? Can you make a guess? Assuming that we wanted to release our software or the first version of our software to the end-user. Well, we're going to first create yet another branch. And we're going to name that branch with semantic versioning. Since this is a very false version of the software we're launching, we're going to name it as we one dot o dot o. So we're going to create this branch out of the develop branch. Meanwhile, other developers can continue contributing to the dollar branch. But what we're going to do next is we need to merge all these changes to the release branch from this particular branch that we've just created. So guess what we need to do next. Way to raise pull requests. Currently, the release branch does not have this feature lead to changes when to get them here. I'm going to go to pull requests, create a new pull request. Here I'm going to choose the release branch and I want to compare it with the version branch, Let's call it. So here are all the features lead to changes. And I'm going to create the pull request. Assuming we've done all the formalities of review, board scanning and all, let us go ahead and merge all these changes. We don't want to delete this branch just yet because it's going to come in handy at later stage. So if you go back to the repository and go to the release branch, you would now have all those features related changes. So we might be running some automated tests and assuming that everything is working as expected, we now have decided to push all this changes our module, these changes onto the master branch so that our customers will start using our software. So once again, we're going to raise another Pull Request. New pull request. Here I'm going to choose the master branch. And here I'm going to choose the release branch. And we're going to go ahead and create the pull request. Let us also merge all those changes to the master branch. Maybe with three bits and merge. We can also Squash commit to combine all the commits into a single commit. But I think we're good with this. So we now have officially released our software to the end-user. So if I click on Master, you're going to see the feature lead to changes here. Ideally, we supposed to create a tag right here. But we're going to talk about tags in upcoming lectures. I'll see you next. 107. 1406 Hot Fix workflow in Action: Okay, let us continue. Now make an assumption that on off your customer has reported a bug and you realize that it is actually a critical bug which needs to be fixed on priority. And so you're not planning to have a hot fix. So what is the first thing we need to do? Well, we already have a branch handy. The one we had previously created with the version name. This is where it comes in handy. We can create another branch out of this branch to fix the bug. And then we're going to merge all those changes in development branch as well as the release and eventually on the master branch as well. So the customers would get an update with the fix. So I have chosen this particular version branch. Let us now create another branch to fix the bug and gets the version we need to give here. Since you're walking on hot fix went increment the value of patch version by one. This time the name of the branch is going to be 101. I'm going to create this branch. Once again to simulate the behavior of fixing a bug. Let me just simply create a file bug, fixed dot dxdy, whatever. And I'm going to commit this change. We now need to merge these changes to development branch. We can either do it from here. We can go to pull the cross-section and raise a new pull request. Choose the branch that we've just created and we're going to compare it with the develop branch. So we have this fixed in here. Create a product class, and let us out. So go ahead and merge the bug fix onto the development branch. And sure enough, if you go back in the development branch, you see the bug fix. We're going to follow similar steps for release as well. We went to raise a pull request. We're going to choose release here. And the bug fix branch cleared the pull requests. And that does go ahead and merge these changes. Now, after a lot of testing, as human things are working great. We're going to go ahead and merge the changes from Release branch to the master branch. As you can see, we now have the bug fix in the release branch. Let's create a pull request real quick. We're going to compare the release branch. I'm sorry. We're going to compare the master branch and the release branch and merge all those changes in the master branch. To go back and switch to master branch should be able to see the bug fix and that's how you deliver a patch. Next, we're going to talk about how we can create tags. And in fact, we had missed creating the tag in the previous version of our software. But we can also create tags for the commits that were already done. How we do that, there is something we're going to talk about next. I'll see you next. 108. 1407 Creating Tags Annotated vs Lightweight Tags Pushing tags to remote: Okay, let us see how we can create tags. We can add the create tags on GitHub, or we can do it from command line from our local Git as well. We're going to see both the ways. First, let us explore how we can do that locally from Git Bash. By the way, in order to save time, I've already added Mr. Luke as one of the collaborators of this project. And here is Luke's account. The first thing that Luke is going to do is that he's actually going to clone this project in his local machine. So assume that this is Luke's computer. I'm going to launch Git Bash here. And let us quickly clone the project. Git clone. I'm going to paste the URI. So let's go inside that project. Clear the screen. So let us now create tags. We can add the create a lightweight tag or an annotated tag. So basically there are two types of tags we can create. When it comes to lightweight tag is just a name or an identifier and appointed to a particular commit. Whereas when it comes to annotated tag, in addition to a name and a pointed to accommodate. It will also have some metadata, like the name of the tagger, email address, date, et cetera. If you'd like to store all the metadata along with the tag, we would better off create an annotated tag and not a lightweight tank. And in most cases, it's always relevant to create an annotated tag or a lightweight tank. For obvious reasons. We will know who has created it when they have created it. And we would even know the email address of the person who have created that tank. So let us first see how we can create annotated tag. Basically, we haven't created tag for the first version of our application. So let us first which to master branch. If I do git branch, iPhone, nay. You see that we have all these branches are remote tracking branches, but we do not have a local branch for the master branch. So in order to get that, let us do git checkout or good switch to master branch. Now let's take a look at list of commits that are in the master branch. So essentially this is where we should ideally be creating a tag which represents the very first version of our application. So this is right before the hot fix we had given. So how are we going to create a tag for one of the previous comments? Let's take a look. So the command to create the tag is git tag, hyphen a four annotated tag. And we're going to specify a unique identifier or a name for this tag. And at the standard practice, we want to give the semantic version of our released. So this is going to be all very first version of our application. And we would now specify the hashCode of the torch. We want this tag to point to. This is as though we had gone back in time and created a tag. At this particular commit. I'm going to paste this hash code. In addition to that, we're also going to provide a meaningful message describing what this tag is about. Some description about it seemed to have messed it up. Let's retype the command. Git tag. Hyphen a. Wee one.org.au specified the hashCode hyphen m. Sum description. If you don't provide the message with hyphen m option, you're going to see a default text editor getting opened up for you to enter some message. If you provide this option though, note etc, would be opened. So this should create a tag for us. If you run the command git tag, you're going to see all the list of tags that are available. So if somebody were to clone the project, they're going to see all these tags as well. Now let's go ahead and create a lightweight tag. And the command for that is pretty straight forward. Get tag and an identifier or a name for this tag. So this time I'm going to say we one dot, dot one. Because by default, when you try to create a tag, it would point to the same commit that the head is pointing to. So currently had this pointing to the latest commit off master branch. And so this tag, which is lightweight tag, because we haven't provided the hyphenate option, is also going to point to the desk commit off master branch, which includes the bug fix. And if you remember as per semantic versioning, we had incremented the value of the patch version by one. Let's hit Enter. And we have just created yet another tag. One is annotated tag, and the other is lightweight tag, which doesn't have any kind of metadata whatsoever. Now how do we publish all these tags to the remote repository? Well, we're just simply going to use standard push command. But we have to specify explicitly that we also want to push tags. By default, push command will not push the tags. So I'm going to let it know explicitly. So we're going to say git push origin is the remote where we want to push all this tax too. We can specify what tag we want to push by specifying its name, the identifier, like so are. We can also say tags to push all the tags to the remote repository. Since Luke has permission for that repository already, were able to push all those tags onto this depository. And you can see them here. If you click on these tags, you're going to see that we have these two tanks will continue next. 109. 1408 Understanding how Tags are stored Detached head state with tags: Earlier we had created couple of tags. One is annotated tag, the other one is lightweight tank. Let us see how they are actually stored in. If you go to refs folder, you will now see this folder with the name tags. And that's where you're going to see these two tags. But they annotate tag is actually stored as an object. Whereas the lightweight tank is similar to a branch, it's not an object. So let's open Washington 101. And it is pointing to a specific comment. Let us try to pretty print this object with that hashCode. Git cat file. First of all, let's take a look at the type of this object. As you can see, it is pointing to the comet object. If you're pretty print this object, you're going to see the details about that commit. But now let's open up the file, which was an annotated tag and see what it points to. Let me copy this hash code, go back to Git Bash and try to print the type of the object. This time, this is going to be of type tag. And if you take a look at the content of this tag object, you're going to see the commit that it points to. And there's also some metadata along with it. Like the identifier of the tag, who has created it, and some description about the tag as well. We can also view the state of the repository at a particular tag by using the git checkout command. So let me do git tag to take a look at list of tags available. And I'm going to use the command git checkout, specifying the name of the tag. Maybe I'd like to get my repository to this date. And as you can see, we are in detached head state. We've already talked about it in one of our previous chapters. But if you go back to the working directory, you're not going to see that hot fix. Because at the time of the creation of this tag, we don't have that fix. Hope it makes sense. I'll see you next. 110. 1409 Releases and Creating Tags on GitHub: Alright, let's talk about releases. As per what GitHub has to say about lasers. Here is what it says. You can create a release to packet software along with the release notes and links to binary files for other people to use. This call, you are going to provide some technical documentation about your release. So you'd want to list down all the changes that are part of the new release. The installation steps, binaries are executables, etc. You'd put all such information as part of the release notes to help your customers or the end-users understand everything about the new release that they need to know. So let's go ahead and try to create a new release on GitHub. And by the way, your organization might be using some other tool to document the release. If you do not have any such tool, we can use GitHub for the same. We can associate a tag for a particular release. We can choose one of the existing ones for instance. Or we can go ahead and create a new tag. And that's how you're going to create a new tag on GitHub. For example, maybe you can say we one dot 0 dot two, or whatsoever. At the moment we do not have any new changes. It doesn't make sense for us to increase the version of our software. Instead, we're going to just use one of the existing tags. Like so. We're going to give it a name. Release V, one dot o dot o for instance. Here. Your bicycle take some time to document everything about the release. So maybe you'd list on all the issues that were addressed, all the new features that were introduced. If there are any deprecated features, you'd want to list them as well. Maybe some installation steps, downloadable, executable, It's etc. You'd put everything that you want your end user to see and understand about the release. And once you're done with that, you would go ahead and publish the release. And this is how it looks. Obviously we haven't populated this enough to really see anything significant. But this is released for you. The customers can go through all the description about the release. And guitar bass automatically uploaded the source code. Would somebody can download if they wanted to. So that's about it. I'll see you next. 111. 1501 Dismiss stale pull request approvals for new commits: Okay, Let's talk about this branch prediction rule that says dismiss tail, pull request approvals, new commits are pushed. What this means is whenever somebody raises a pull request and also assume that even the review is done, but that pull request, now before merging those changes on to some other branch led to a dollar per kilometer team or changes in the branch that we want to merge. Now, should we allow the changes to be reviewed once again, are not his ward. This option is saying, if we enable this option, that means that we want to mandate the review process, once again, reviewing all the latest changes before it can be merged onto another branch. Disable this option, then note abuse needed to merge the changes. If you've understood what I've just said, that's well and good. You can skip the next video. Otherwise, just hold on. I'm going to demonstrate the same. So right now this is disabled. Let me go back to the depository and quickly raise a pull request for that. Let me create another branch with some random name is df. And let's also have one commit. Maybe by adding a new file. Let's give it some name, something of that sort, and commit the changes. Let's raise pull request. We're going to compare main branch with the branch that we've just created. Create pull request. Create pull request. So this has created the pull requests. We need at least one approved review before we merge these changes. Now the same person who has actually raise a pull request cannot review his own code. For that. I've already added Mr. Luke as one of the collaborators of this project. Let me know, go to Luke's account and quickly accept the changes. So here is the pull request from the Luke's account. And I'm going to add my review I'm going to review these changes, approving everything. Now if you go back to sum those seconds, you're going to see that the changes were approved and that I can go ahead and merge the pull request. But meanwhile, before merging the changes, let me try to make another commit in the new branch that we've just created. I'm going to go back to the code base and to that branch. And let me add another file with some other random name, like so and commit the changes. If we go back to the pull requests, you're now going to see those new changes as well. Right now you can see that no additional reviews needed to merge the pull requests. That's because this option right here is disabled. Let me enable this option. Save Changes. Let me quickly enter the password. And now if I were to make another change and commit to this branch, let me do that real quick. Something of that sort. Commit the changes. If I go back to the pull requests, this time, you'll see that we need at least one review once again before we can merge those changes. Well, since Sunday is the owner of this repository, is able to see this option to actually merge without waiting for the comments to be met or without the viewing to be done. But ideally the lapels will not be able to see this option. But I hope you got the point of this branch protection rule. I'll see you next. 112. 1502 Configuring Code Owners with patterns Automatic review request: Let's talk about this branch protection rule would say is required review from code owners. Basically github allows us to create a special file with the name code owners, Wherein we can specify who owns what based on file patterns. It is somewhat similar to the patterns that we're specifying a dot gitignore file. But we also specify who owns the files that correspond to those patterns. And by enabling this option, called on us would automatically be requested for review. Whenever somebody raises a pull request that modifies the code that they own. I know this sounds confusing. And that's why I'm going to quickly demonstrate the same phosphor. Let us go to our repository. And I'm in the main branch here, I'm going to create a new file. I'm going to name the file as code or nurse. It has to be exact same name, all capital letters. And inside this file I'm going to specify one of the owners with a pattern. For example, I could say star dot js and all the files with dot js extension would be owned by let say, look, we already have look at it as one of the collaborate to solve this project. So wherever you're going to add as owners, they need to have write permissions to this project. So let me quickly copied the Luke's email address and pasted here. You can also add the username of Luke. Either way, luke is now going to be the owner of all these files. Let me come at this file. Now let me try erasing pull requests with ab.js file 1. Second, let me just quickly create some random branch. And let me quickly add a new file. Scripts dot js. Convert the file. Let's now go ahead and raise the pull request. And the moment I do that, you'll see waiting on code owner review from Luke's under Corp. Now if you go to Luke's account, if I click on the pull request, this is Luke's account. Look is going to say this message saying that he needs to review a pull request. So since the fact that Luke is the owner of all dot js files and somebody raised pull request on the same branch where Luke was added as the owner of these files, get has automatically asked Mr. Luke to review the changes or the pull request. So look, can now do something with this review. Let's say that he has approved of the changes. And now we can go ahead and merge all the changes. This option is already enabled. I had already enabled it and saved the changes. And hence, this has taken effect. If we disable this, then Luke wouldn't have been receiving the review request. Let's go back to the repository. Generally we keep code owners file in the base branch or the default branch. Since this file is currently placed in the main branch, manager or somebody raises pull request asking to merge the changes to this branch. That's when this code on a spiral would take effect. So you'd want to keep this file in a branch where developers would contribute their code to. End. By the way, there are other bunch of patterns we can use for that you can defer to the official documentation, are at also provided notes giving you some of the example patterns along with some description. I'm going to keep this as a notes you can download and take your time trying to understand this. It's actually pretty straightforward. The patterns are pretty much similar to the patterns that we include in dot gitignore file. Except we're going to also specify the owners has two horns of files corresponding to those patterns. You can also specify teams. So team would be owning particular set of files. Like in this case. If you take one out debate memberships of GitHub for your organization, then you can also add deems. Hope it makes sense. I'll see you next. 113. 1503 Mandating conversation resolution before merging: Okay, Let's talk about this branch prediction rule that says required conversation resolution before merging. And by the way, we're going to ignore talking about this option because this has something to do with external tools. And basically, if you want to perform many kinds of checks before merging the code into another branch, you'd want to enable this. And talking about This is definitely outside the scope of this particular course because this has something to do with external tools. But generally speaking, if you want to perform any kind of checks like vulnerability scan, are checking to see for any programmatic errors in the code. Our perform continuous integration or maybe deploy the code onto a build server, get the build status, et cetera. If you want to work for many such kind of things, whenever somebody raises a pull request, you can configure them here. And this actually completely depends on your organization standards and we need to follow accordingly. So maybe we'll cover all this in other DevOps courses, but we're going to ignore it for now. Let's get back to this option that says required criminalization resolution before merging. Let me enable this option. Demonstrate to you what it exactly means. So basically the men to the password real quick. So this option is enabled. Let me go to the pull requests that we had raised earlier. And as you can see, we can currently perform the merge because of their view is already done. But let's say that Mr. Luke has one comment to add in the code. So let's go to Luke's account. Let me open up the file from this pull request. And let's say that we have bunch of lines of code here. And Luke is putting in some comment. So maybe something like something of that sort. Let me enlarge it a little bit. So I want to add this command, and we're going to click either of these buttons. Let me just add single comment. And since the fact that we had enable that branch protection rule option, if I now go back to the pull request from senders account, let me reload the page. You're going to see that the merge is blocked Once again because there are unresolved conversations. Let us assume that sender has addressed this comment and he's going to mention the same replying back to look. Yes, I have checked that. Something of that sort. That is once again, go back to Luke's account. He's gone to see the reply here. And once you're satisfied with the reply, Luke is going to resolve the conversation. It is. Then sender can actually merge the pull request. If this option is not enabled, then conversation dissolution is not needed to merge the code. I'll see you next. 114. 1504 Exploring all other branch protection rules: Let's talk about all the remaining branch protection rules in here. These are pretty easy to understand and already straightforward. And so we can fit all these in this video alone. Exit this branch prediction rule would say is required signed combats. This actually requires you to understand what are assigned commits, how we can generate private and public keys for signing, encryption, decryption, et cetera. So this deserts at chapter of its own. So we're going to talk about this in next chapter. But let's wrap up this chapter on branch prediction rule after quickly touching on all the other options we have here. So we have this option that says required linear history. And as the name suggest, it doesn't allow us to have merge commits. If you have a merge commit, we would no longer be having linear commit history. So let's say that I have enabled this option. Let me save it real quick. If you go back to the pull requests, let me click here. This is the pull requests we had raised earlier. Now if I choose this option to create a merge commit, you're going to see this message saying, the Merge branch requires linear history. That's because we had enabled that option. But still we're able to see this option to merge pull request. That's because I'm actually doing this from this under second, who is the owner of the repository? Let me edit this branch prediction rule. We have yet another option to not let that happen. So here it is. If we enable this option that says do not allow bypassing, they're both settings. And the description of it says the elbow settings will apply to admins and custom roles with the bypass branch protections permission. What this means is so far all the branch production rules are not really applied for admins, are not really enforced for admins or to the owners of the repository. By enabling this option, admins are the owner of the repository, cannot really bypass the branch production rules. Let me enable this option and save the changes. Now if I go back to pull request, Sender being the admin of the repository, would no longer be able to choose this option. This got grayed out. I cannot click it either. If you take the organization license of GitHub, you should be able to create team of individuals. Some of them are Edmond, Some of them are maintainers. They might have different roles. And by enabling this option year-old's enforcing branch prediction rules given for admins are the maintenance of the repository. In-between these two options, we have this option that says required deployments to succeed before merging. Well, you can use this rule to ensure that changes are successfully deployed without an issues to this staging or the testing and Romans before the changes can be merged to the default branch. Now this depends on your organization that tools that you're using. Currently we do not have any deployment and Roman setup. So we really cannot demonstrate this. Maybe this is topic of another course. So we're going to skip that. And we're left with couple of branch prediction rule options. And these options are applicable to everyone including administrators. Hello, force pushes would mean that we want to load the force pushes to the protected branches. And we can even choose who can do that. Whether do we want to allow everyone with push axis, like collaborators for instance? Or do we want to specifically choose whom we want a low force pushes? For example, Luke is already added as one of the collaborators. I can choose him, for instance, if I wanted to. And finally, we have a load deletions. So by enabling this option, we're allowing people with Bush Axis to be able to delete the branches that match with this pattern. In this case, we're saying all this branch prediction rules are applicable for main branch. And so by enabling this option, we're allowing people with push access to be able to delete this particular branch in this case. So that's all about branch protection rules. Once again, we're going to explode this option. In next chapter. I'll see you next. 115. 1601 Mimicing the Commits and the need to have vetified commits: Now let me demonstrate to something really interesting. I'm sure you'd be surprised to see this happening. For the sake of this example, I'm going to be using one of the existing repositories that we've been using throughout this course. In case if you lost hold of what this repository is about. Just think of this as some random repository with bunch of files in it. Currently this project has these two collaborators. We have sender who is the owner of the repository, and Luke, who is one of the collaborators of this project. Also for the sake of this example, I have disabled branch production rules for the main branch. And hence you're seeing this message that says your main branch isn't protected. Now a question to you. Is it possible that Mr. Luke make a comment on behalf of cylinder without taking his consent? Well, let's take a look. Imagine that this is Mr. Luke's computer. And to save your time, I've already cloned the project. Let me open up Git Bash here. Let me run the command git config lest to take a look at the current configurations. And as you can see, username and email are off. Mr. Luke's username is Luke's in the Corp and email address is looks email address. Let me try changing them to Saunders. I'm going to say git config global username. I'm going to give the same dose GitHub username, like so. And similarly, we're also going to change the e-mail address and update it with some those e-mail address. I can easily get this in this name and email address. But on in the git log command. And taking a look at some of the comments done by Mr. cylinder. Now if I do git config list, you're going to see that the username and the e-mail address or no, updated with cylinders is a name and his email address. Let me now try to make a commit and see what's going to happen. Let me quickly create a file with some random name. And I'm going to stay as that file real quick, git add name of the file. And finally git commit with some message. Let's call it wrong commit. And I'm also going to push these changes to the GitHub repository. Now let's go to GitHub and take a look at how things got reflected over there. I'm currently in the main branch. Let me reload the page and go to commit. And as you can see, we're able to see the commit that was just made by Mr. Luke. But if you notice what is being shown here, it says this commit has been made by Mr. Sunda and it is pointing to cinders profile. Interestingly enough, some that does not have any clue that this comment has been made. For somebody who looks at the commit history. They're going to think that this committee is actually made by sunder all day, does not him who has actually made this comment. This is happening because good assumes that what are they using them? An e-mail address that was set in configurations is the same person who is actually making the commit. However, that may not be the case. And I've just demonstrated it for you. This doesn't necessarily have to be done by existing collaborators of the project. Some random person for the project, and raise the pull request with bunch of commits mimicking that those comments were actually done by some other user, which is obviously not something we would expect to happen. So we need some sort of verification process in place that checks to see if the commit author is the same person who has actually made the committee. And that's where verified commits will come into picture. And that's what we're going to talk about next. 116. 1602 Understanding Digital Signatures: Before we understand what our sign commit, let us try to understand what exactly is a distorted nature. Not in the context of Git and GitHub. But in general. Assume that we have Bob and Alice. And Bob wants to send a file to Alice. If he sends the file as it is to Alice, then it might happen that somebody interfere in the network, manipulate the file before it reaches to Alice. And Alice doesn't have any way to verify if the file has been manipulated or if Bob is actually the sender. So keeping that in mind, bob is going to do something about it. What is going to do is he's going to use some kind of a tool to create so-called public key. And a private key. Private key, as the name suggests, is not supposed to be shared with anybody else. It is going to be with Bob. And it's going to securely keep it somewhere in his local file system. On the other hand, public key can be shared with anybody else. Anybody who want to receive Bob's message or file can actually have a copy of the public key. In this case, Bob is going to share the public key with Alice. Alice gives would come in handy in just a while. So this time, before Bob sends the file to Alice, is going to use his private key to digitally sign the document. But what is the distance that nature? Well, digital signature is essentially a hash of the data that is encrypted, but signer's private key. We already talked about hash in one of the previous lectures. But just to summarize, hash value is a numeric value of a fixed length that uniquely identifies a data. Or in this case this file. If you do the same data or the file as an input to hash function, it would do the exact same unique hash value no matter how many times you do it. But if you change the data or the contents of the file even a little bit, the hash function would return an entirely different hash value. So essentially, hash value uniquely identifies a given data or a file. When I say data file or a message, they all mean the same thing. So Bob would then send the file to Alice over the network. Now Alice has to verify if the message has been manipulated out of the sender is actually bombed. I wish you're going to do that. Well, she's going to use Bob's public key to decrypt the digital signature to extract the hash value out of it. Well, when I say she's going to do that, It's not exactly her who will do that. She's going to use some kind of a tool that does that. She would then use some kind of a tool to find out the hash value of the file sent as well. These two hash values are exactly same, then we can be sure that data has not been manipulated. And if she is unable to decrypt the digital signature, that means somebody else has send the file using their private key and not Bob's private key. If the digital signature is signed with somebody else private key, Alice wouldn't be able to decrypt the discursive nature using Bob's public key. So that way she can be sure that the file has not been manipulated and that the file is actually coming from Bob. If you've understood this, then understanding verified signature shouldn't be a big deal. We're going to talk about verified signatures up next. 117. 1603 Understanding Signed Commits: Let's now talk about verified commits. The concept of verified comments is no different from the concept of digital signatures we've talked earlier, except in place of Bob Dylan to have get in place of Alice. We're going to have GitHub. And in place of this file, we're going to have the comma. Let us assume that Luke wants to distal assign a commit and push it to the GitHub repository. On GitHub, we want to verify if that commit has actually come from Mr. loop. So initially, Luke is going to generate public and private keys, is going to upload his public key on his GitHub account. And he's going to use the private key to sign the comments. Once again, it's not exactly Luke who would do all that. It would all be taken care by get, by just running a simple command. When it runs that command, git is essentially going to distal assign the commit. And once after loop pushes the commit to GitHub on the GitHub site. Github will verify if it has come from Luke by using his public key. Let us take a look at details steps involved in this entire process. So initially local, gender, public and private key using some tool, it would then upload the public key on his GitHub account so that GitHub can use it to verify the commits. Local distal assign the commit using his private key. By just simply running a command. Luke will then push the changes to GitHub. Github will verify the commit by using Luke's public key. If GitHub cannot decrypt the Comanches and looks public key. It means that the comedian come from Mr. Luke. Somebody else might have made that commit isn't their private key. We're going to see all this inaction up next. 118. 1604 Createing Public and Private Keys Using GPG: Okay, let's see how we can create public and private keys. Now assume that this is Mr. Luke's computer, and he's now planning to create public and private keys for himself so they can be used at later point in time for verification. To create those keys, we are going to be using a tool called GPG, stands for GNU Privacy guard. And it is something that you don't have to install separately. If you already have Git installed on your computer and get to already comes bundled with GPG tool. And you don't have to install it separately. In case if you're not using Git Bash, than with a quick Google search, you should be able to find instructions on how to install GPG for your operating system. However, in this case, we're going to be using Git Bash for the same. And also make sure that you don't run these commands on the repository folder. For this purpose, I've actually created a new folder on my desktop and this is where I'm going to run the commands. So first of all, let us make sure that GPG is indeed installed by running the command GPG dash dash version. And this should show an output like this. Now let's run the command to create the public and private keys for Mr. Luke. The command for that is GPG, dash, dash, dash, generate key. This is going to prompt us with few questions. Let's see what we can answer them. Here we need to choose the algorithm we want to use to generate the keys. Gpt supports all these algorithms that are listed here. The default one is RSA algorithm, and it is the algorithm that I recommend to use. So I'm just simply going to hit Enter to choose the default option, which in this case is RSA algorithm. Next, we were prompted to enter the key size. The maximum key size we can enter is 4,096 bits. And this is the minimum requirement for GitHub. So we're going to say 4,096. Hit Enter. Here it is asking us to enter how long the case should be valid. I want it to be valid forever. I'm going to leave the default option, which is 0. So k would never expire. And we should be able to use these keys forever till the time we delete them or do something with them. Let's hit Enter to use the default option. Now it is asking us to conform if we really intend to not expired the key at all, I would type in y, just say yes, hit Enter. Now it is asking us to enter the User ID. Here. I'm going to provide the username of Mr. Luke's GitHub account. I already have it handy. I'm just simply going to copy paste it here. And of course, in your case, you need to enter your GitHub username. In the next prompt, I'm going to provide Luke's email address. In your case, you want to provide your email address that you used to register for GitHub. So essentially what are the name and email address you want to use to make your commits? It should provide them over here. We can optionally also provide a comment, but I don't like to provide anything. So I just hit Enter. Now it is asking us to verify the user ID that we've just entered. So double-check and make sure that it is correct. Once your shirt off it, just enter the character o to say L K. Keys are being generated. Now you might get a prompt asking you to enter the passphrase. This is just an additional security to protect your private key. If somebody were to steal your private key, they should be able to know this passphrase to be able to use your private key. This is just as an additional security measure. You can just simply press OK without entering anything. That way, you do not have any passphrase. However, it's obviously recommended that you provide a passphrase. In my case, I'm just simply entering for cactus, which is not so secure. If you want it more secure, then give a very strong passphrase with combination of characters, numbers, symbols, etc. And my guess is just going to be four characters. It okay? You get another prompt warning you that the password is not very secure, as it is very easy to guess. But I'd like to use that one anyway. So I choose this option that says take this one anyway. It is asking me to re-enter the passphrase. I'm going to do just that and hit Okay. Now, while the key is being generated, it is recommended that you perform some activities on your computer like moving the mouse, are entering something on keyboard, et cetera. And that's what is being recommended here. It says, we need to generate a lot of random bytes. It is a good idea to perform some other actions like typing on the keyboard, moving the mouse, utilize that, this, etc. So that the key that gets generated is more random. So both are keys were generated. You can verify if they got generated by running the GPG command with the list case option. So I'm going to say GPG dash, dash, list, dash keys. So this has shown the public key. And if you say list dash, secret case, this is going to display the details about the private key. These are not the actual case. These are just the details about the keys. This will come in handy in just a bit. I'll see you next. 119. 1605 Exporting Public Key and updating GPG key on GitHub: Okay, Now that we have created public and private keys, let us now try to export the public key so that we can put it on Luke's GitHub account. And the command for that is, you're going to set GPG. Hyphenate stands for armor. This option is to export the key in ascii or mode format instead of binary. And then we're going to say dash, dash, export it to export the key. And then we're going to specify the key ID. Now what is the key ID from our previous commands? If you notice, where we have verified the public key and private key creation, it has also printed the key ID. And if you notice, the key idea of both public and private keys are exactly the same. That's because the private key do not have a separate key ideas such. And so GPG is just showing the public key ID that the private key is paid to. I'm just simply going to copy this identifier. Alternatively, you can also use UID stands for User ID, and we can use the same as well. But it's generally recommended that you use the key ID instead of the UID. Because long story short, it might cause conflicts if you have a KeyStore. So let's use this to export the public key. We can copy the text from begin PGP public key block. All the way to this point where we see the text and PGP public key block. I'm simply going to copy it. Alternatively, you can run the same command. And using angular brace, we can actually export the public key on their file. Public dot key, for instance, where the public you would be exported. If you wish, you can also export the private key. At the moment. We don't have to do that. But I'm just demonstrating how we can do that. So instead of saying just export, we're going to say export dash secret key. And this would export private key as well. And when you do that, you're going to get a prompt asking you to enter the passphrase. In my case, it's just for character passphrase. What are the passphrase you have created? Intended that here. Once I hit Okay, we have the private key dumped into this file. So let's see if we can go there. If I open up this directory, you're going to see these two files created. Let's open public dot key file with Notepad Plus, Plus. And you're going to see the same text that were seen on Git Bash. I'm simply going to copy this. And I'm now going to go to Luke's GitHub account. This is looks GitHub account. I'm going to click on this icon. And if you scroll down a bit, you're going to see Settings. Click on that. And on the left-hand side menu, click on, click on SSH and GPG keys. And here you see option. To give a new GPG key. Under key section, you're going to paste mortar have just copied the public key, optional Ignacio title, and click on Add GPG key. Next we're going to see how we can sign the commits. I'll see you next. 120. 1606 Making Signed Commit Setting global config verifying signed commits on GitHub: Okay, let us see how we can make assigned commit and get them verified on GitHub. I already have the mind public CAP cloned here. Let me open them, get bash on the projects root directory. Let me first run the command git config list. And as you can see, they use the name and email are updated to that of cinders, which is not ideal. Let's see what's going to happen once we make assigned to commit. So let me create a random file, something of that sort. Let me stage it. And by the way, I'm not doing this on the main branch. I've just chosen somewhat random branch. In this case, the branch name is QQQ, which will randomly created in one of our previous lectures. Let me not try to make assigned to commit. The command for that is git commit. Hyphen uppercase, Yes. Make sure that this is uppercase. Yes. Otherwise, this one walk. If you want to sign it tag though, then it has to be a lowercase. Yes. So hyphen uppercase yes. And hyphen md to provide some message to this commit. Let's call it my commit or whatever. So commit has failed. And the message says that there is no secret key. For Mr. Sunda. The user ID of the key that we have created is to that off Luke's. But the good conflicts are having the credentials often though. They both did not match Enter. We're not able to make a sign to commit in this case. So let us quickly go ahead and change the configurations. Username is going to be GitHub, username of Luke. Similarly, we're going to update the melodramas to that of looks like so. Now let's try to make assigned commit. For the first time you do it. You'd be asked to enter the passphrase. I'm going to enter just that. Hit. Okay? And our commit to successful. Let us try to now push these changes to GitHub. So we're able to push this commit that has go to GitHub and see what got reflected over there. So I'm currently in my public app repository and I'm in this branch, QQQ. Let me reload the page. And as you can see, we're able to see the comment that was just made. And this time it is with verified badge. So github is able to fetch the public key of Mr. Luke, the author of The commit, to verify if the committee is indeed done by Mr. Luke. That's how the verification process happens. If I were to remove the public key from Mr. Luke, then the verified badge would no longer be there. You might say Get up saying that verification is unsuccessful. And by the way, if you do not want to do hyphen S option every time you wanted to sign a commit, we can actually introduce a good conflict for that. So you're going to say git config global climate dot JPG sign. And we're going to set this to true. So every time you want to make sign commit, you don't have to explicitly provide the hyphen S option. If you set this flag. Additionally, if you have multiple private keys, to avoid ambiguity, you also need to let them know which private K12 use to sign the commits. The conflict for that is user signing key. And you're going to provide the unique ID of the key, GPG. Keys. You can provide this id. Like so. Let's say there's a person with negative intent. He has created a private key using Luke's credentials and assume that he has even pushed the commit to the repository on the GitHub site. Github will not be able to verify that commit using the public key on Luke's account. And that way get up would be able to verify that the committee is not actually coming from Mr. Luke. Hope it makes sense. I'll see you next. 121. 1607 Mandating Signed Commits Signing commits from VS Code: Okay, Let's not talk about this branch prediction rule that we had left out earlier. It says required signed commits. You should be able to understand this by now. If you enable this option, what that means is we only want to allow sign comets in the matching branches. As simple as that says, This video is going to be very shot. Let me also include one more thing. Let us take a look at how we can have signed commits from Visual Studio Code. For that, let me open up this project using Visual Studio Code. So the setting for that is you need to go to File menu, Preferences, settings and search for. Let me do it again. Settings and search for GPG. You need to enable this option that says enable commit signing. Close settings. Let's quickly make an edit in one of the files just so that we can commit something. I've been put in some random text, save the file. And let me commit the changes. Sign from VS code, something of that sort. And let me make the commit. You might be prompted to enter the passphrase. Please enter it and click. Okay. Since I've already done this before, I didn't get that prompt once again. But if you go to GitHub now and you reload the page, of course, we need to push those changes to be able to see them on GitHub. So let's quickly do that. Let's reload the page. And as you can see, we're able to see that commit and it is verified as well. Hope it makes sense. I'll see you next.