Learn Git & Github From Scratch 2026 [Easy way]

1. Introduction of Git Masterclass: Welcome to the ultimate it course. In this course, we are going to learn it from scratch to more advanced concepts. We start with what is it? Why every company loves it, how Git really works, configure Git in our system. Git basics like staging the files and commit the ignoring some files. After that, we have complete section for browsing the commit history. In that, we can compare two commits, return to specific it, adding texts. After that, we have section for branches and merging, which is the most important topic of kit. We will also see test the changes, different types of merging, resolving conflicts like Pro, types of reset, cherry picking technique, after that, we have section for working in team in which I will show you practically how team members work together using it. In that, we have cloning, padging, pull, push. Also some additional features of github like releases, issues, milestones, contribute in open source project. After that, we will see how to organize our project history so our project looks more professional, Modify existing commits, splitting and squashing them much, much more things. So in this course, we will learn Git both ways. First, we will see Command line approach, and then I will show you how we can do the same using GI tools like Gitub desktop, Visa Studio code, and Git Gracon. But as you might know, GI tools has little limited features. So that's why learning Git commands are very important for us. If you don't know anything about Git or you are confused about Git concepts or you want to master kit and Github, then this course is for you. Now you might ask, who am I? I'm a software engineer and also teach programming in easy to explain language using my YouTube channel, God bless you, and with my online courses. And in this course, I will also give you some projects on which you can practice the kit commands by As you can follow along with me because when you write Git commands by your own and experiment with them, then you will understand it commands properly. Making mistake, learn from the mistakes, and do it till you mastered that skill. After completing this course, you will properly understand how kit works and you will use it confidently without getting confused and using best techniques. I know you are excited to learn it and Github, so as jump in and dive into this course. 2. What is Git & Github?: So before we start learning gait, let's see what is Git. Git is the most popular Version control system. Now you might ask what I mean by Version control system. Version control system means it helps us to keep record different versions of our project. Let me explain you with one real world example. Imagine you are working on an ecommerce application. Now after some time, you really messed up with your code and you can't identify errors and can't solve them. You decide to start from scratch. Now, what is the solution that this situation will not happen again? One solution is you can duplicate your project and give it name like version 1.0. And store it somewhere as backup. So if in future, you messed up again, you can go back to that version 1.0 code. Now, as you introduce new features, you keep taking backup and creating versions of your application. But manually taking backup leads to many problems, like storage problem. Also, it creates a lot of confusion, like in version 1.0, which features we added or removed. Also, imagine you have one more team member working on the same project, then you have to so your backups and what change in those project, you can't track. It creates a lot of confusion and stress for team. At that time kit comes in the picture. Kit helps us to store different versions of our projects very systematically and without taking extra storage. Suppose you are working on index dot SML file, you want to take backup of its current code. You tell Git, save this file code in history. G take snapshot of your code and simply store it in its storage. Now, as your application grow, you take multiple screenshot and store them in Git storage. When you want to see particular version, then Git show you history of your project and you can easily restore that code. Now you can say we understand Git track our project history, and that's why we don't need to worry about manual backups, but how it solve problems working in team. Is another issue. Let me quickly explain you that. Here you and your team members individually working on the same project, and you both use kit for tracking your project history. Now, when you're done with your one task, then you can take your code snapshot in Kit and upload that project on Cloud service, which allows us to upload kit projects. Now your team member get your Git project or folder from this Cloud service and start working on that. When he done with the bog, then he can take snapshot and updated changes on Cloud service. And can you guess which Cloud service used most by developers? Right, it is Github. Git and Github is different. Git is a version control system, and Github is used for hosting Git projects on Cloud and also Github provides more features. By using Git and GitHub, we can easily work in team without sending each other email back in front. Don't worry. We will understand this very deeply in upcoming section. In fact, we have whole section where I practically show you how developers works with each other. To quickly cap, it is the most popular version control system. With Git, we can track our project history very effectively. So we don't need to worry about manual backup and recovery. Also by Git, we can know when particular changes are done with date and time and also who did those changes. Also, Git makes collaborating with team members very easy and many more benefits which we will see in this course. That's why almost all companies want developer who know Git very well, and that's why every developer needs to learn Git and Github. Here in this course, we are going to learn Git very deeply. I'm very excited about this and hope you are too. See you in the next lesson. 3. Various ways to use Git: Now, let me show you the various way to use Git as developer. So first way is you can use it in Command line, which means you open your terminal and start writing commands for accessing Git. This is one of the simple and easy way to use gate, and many developers prefer command line. Now, if you don't like to use command line approach, then you can use our code editors for accessing the gate. For example, in VS code, we by default, get the source control panel. Using this panel, we can perform basic operations of git. Now you might ask, what about we want to use more git features? Don't worry about that. We have one VS code extension called Gitans which is the most popular and most use Git extension. You can see that this extension is downloaded by almost 30 million users. You can also use this extension. Now, another way to use its by using graphical user interface or GUI. GI means we can use application which is specially made for using Git. Nowadays, the most used and simple Git application is Github desktop. Gitub desktop application made kit so simple for the Gate beginners but it's super simple and easy to understand structure, but it has not all it features. If you want to use another GI tool, which have more features than Github desktop, then you can use Gate gracon. This is also popular tool for Git, but its user interface is little complex than Github desktop application. But at the end of this course, you will definitely like Gate gracon. Will show you why in upcoming sections. Now you might ask, which is the best way to use it? And the answer is the command line approach, and 70% developers like to use Command line approach. First reason is this all GI tools, whether it is Github desktop or it Kraken, comes with some limitations, which means for some task, you definitely need to use Command line. By using command line, you can perform all tasks related to Git. Another reason is I tools are not always available to you. For example, sometimes server don't allow to use GI tools for Git for some reason. At the time, if you don't know Git commands, then you will get stuck in this situation. Most of the time, many developers like to use both GI tools and Command line, and I'm also one of them. That's what I will teach you in this course. We will learn command line approach first, and then we will also see those concepts using GI tools. You will learn both ways and then you have to choose right tool for the task you are performing. Let me tell you one incident in my company where I worked as software engineer. There was one guy who performed all kit task using command line, even complex task also. He thinks he looks cool to use command line for every task. But we all know we can perform that task much easier using I tools. So don't become like that guy. You have to think smart. By which way I can complete this task faster and without getting confused. We will spend most of our time using command line because it is faster. But when I think using I tool is more beneficial, then I will show you so GI tool way. Also, many beginner developers are very afraid of using command line, or I can say remembering the commands for gait, but don't worry, I will teach you everything in simple step by step and easy way than you think. You will get the confidence to use Git like professional. Now in the next lesson, we will see how to install Git in our system. 4. Setting up Git in our system: So let's install Git in our system. But before that, let's check if Git is already available in our system or not. And to do that, we use terminal. So if you're Windows user, then press Windows key and type CMD. And if you're Mcuser, then press Command plus space and type terminal. I am using Windows, so this is how my terminal or CMD looks. Your terminal might look different. It doesn't matter. So first of all, here we type git version to know which Git person is installed in our system. See here we get Git is not recognized as an internal or external command. If you are getting the same message, then it is not installed in your system, and if you get version, then you have to make sure that version is not too old like two or older than two. Make sure you update your gaiterson with that, you can easily follow along So to install or update Git, we open our browser and search here Git download. Open this post it website. Nice. So the latest Git version is 2.44 0.0. If you're watching this course in future, you might get different version, but don't worry, you can still follow this course. Trust me, you don't get any error. From here, you can see like your operating system, or we can simply click on this button. Click here to download and see it start downloading g. Lovely. Now, let's open this setup. First, it will ask for permission. So allow it, click on next. Here you can select Installation path, so click on next, next, next, and from here, we can select our default code editor. I'm going to use Visual Studio code or VSCode because almost 90% developers use VSCode and click on next. Next, and click on next. Next, click on next. Click on next until you get Install and installation is started. Done and click on Finish. Now open start menu and search Git Bash, which is the command line interface for providing the terminal interface for Windows system. For the rest of this course, we will use Git base CLI for writing Git commands. If you are Mguser, then you have to use your terminal because it base is only for Windows. Here we write Git dash dash version and C, here we get our Git version 2.42 0.0. We successfully install Git in our system. 5. Configure user details for git: Now to start using Git, first of all, we have to do some configuration settings like user name, EID, default code editor, which we already set while installing Git and also line ending configuration. Don't worry. They are very simple. Now we can set these configuration settings at three levels, system level, which is for all users in this computer. Second level is global level, which is for all repository of the current user, and third level is local level, which is for the current repository. Don't be scared, just do as I do. Open up terminal or itbashF of all, we write it config for global level, and we add user dot name. Here, we add double codes and here I enter my name. Let me zoom a little bit using Control and plus, or we can use Control and mouse scroll. Good. Now hit Enter. Here, we use double codes because we have a space in our value. Also you have to write your correct name here. Whatever name you write here, you can see that name in repository history. Now let's add email in the same way. Press up arrow that will return previous command, and here at the place of user dot name, we write user dot email. And here we don't have space in our value. We can remove these double codes and simply I write here my email. Now let's set our default code editor. As I told you, in this course, we are going to use VS code. If you don't have VS code, then you can download it from code.visualstudio.com. Now back to our Git pash and we write Git config dash global co dot Editor. Here, we also add double codes code, which is visual studio code, wait. Now you might ask why we add here wait? This weight will tell our terminal to wait until we close the VS code window. Here, get store all our configuration settings in the text file and to view or edit that pile, we write config Global E. Hit Enter. See, here we get configuration file in via code. From here, we can change the configured values and if we go back to our Git pase here we can see it is waiting for our editor to close the file and that's because we add here wait. Let's close this Git config file and see we exit from it. Now we almost done our config settings. Just we have to do one config which is for end of lines. This is very important setting which a lot of developers miss forget. This setting is very useful when you are working with cross platforms. For example, you are using Windows as operating system and another your colleague using Mac operating system. When you add text file to Git for Windows, that file use R N, which are special characters used in textFile to manage the layout and structure of lines in document. But in MacOS or Linux, textfile use only N. So if we don't handle end of line property, we get some weird issues in Git. Now to fix this issue, we have config setting called AutoCRLF which is carriage return, and line feed. So here in our example, if we add our code in Git repository, G remove all carriage return and replace it with the line feed. Now, when we again want to get the same code, then Git will again update our code with carriage return and line feed both. So here we need to set this CRLF property to Tru which automatically converts this code. Now when a Mac or Windows user adds the code to the same repository, then gait, don't have to update that code because it is already in the line feed. Here, for Mac and Linux users needs to set this AutoCRLF property to the input, which is the original type. Don't worry about this. You don't need to understand this so deeply. Just do as I do and you are ready to go because setting the config is one time process. In our Git Bach we write Git config Global. Co dot AtosRf to True. If you are Mac user or Linux user, then here at the place of True, you have to add input and hit Enter. Here, our configuration is done. Now we can start learning Git. 6. How to make Git Bash Look Good: Now, currently, our gdbash look like this. Let's make our Gitbash look cool. It's fun. If you're using simple terminal in Windows, where I suggest to open gtbash, right click on the Gitbsh and here at the bottom, we get options. Here, we can select colors or we can select theme. Here, we get many themes. So these are very decent themes. I personally like Dracula theme. See, this looks nice. After that, we can change transparency and cursor and we can select blinking cursor. Now let's go for text. Here, we can select fonts. You can try to change these fonts. I'm happy with the current font, so I can sell it. Also, I smooth the fonts to full and apply and save the settings and see our Git pash look like this. If you want to try any other theme or any other fonts, then you can do that as well. I'm happy with the settings. Now let's start learning git. 7. Section 02 Git Basics: Welcome to the second section of the ultimate Kit course. In this section, we are going to learn very fundamental concepts of kit, which every kit user should know. So first, we start with the understanding the workflow of the kit. You will learn how Git really works, how to initialize it repositories, recording code history, staging, committing, which are really important concepts because many developers don't know how it works, and then they get confused a lot. So watch this complete section, even if you know basics of kit, because a lot of developers really misunderstand these concepts and get stuck with kit. So watch every lesson of this section. Let's dive into this. 8. Initialize the Git Project: So to start working with Git, first of all, we need to add Git in our project or folder. If we don't add Git in our project, how should Git know which folder it has to track? Here I am in the project's folder, and here I create a new folder, let's say, Task track. This is the first project name which I created in my ultimate react JS course. Also, don't worry about this. We are not going to create any specific project. Here, our main focus is to master Git. Now we need to open this folder path in our terminal or Git Bash. If you are Windows user, then right click here and you get the option for opening Git Bash here. See, we open our folder in the Git Bash, and if you are Mcuser then right click on your folder and you will get the option open new terminal at the folder. Now let's initialize Git in our folder. Here, we simply write Git in it and hit Enter. See here we get message initialized empty Git repository with our folder path. Also we can see here we get master, which simply means our folder is ready for it. Now, if in our task track directory, directory means folder, we get another directory called.it. If you don't get that folder here, go to the view option and check here hidden files. By default, this directory is hidden because we don't need to touch that. But let me show what is inside this folder? Basically, Git folder stores information about our project history. See, here we get a bunch of folders like hooks, info, objects, references, and some other files. If you're using it, you don't need to worry about all these files. These files are implementation details about it, how it store information. Don't worry about that. It's not our business. Our goal is to use Git and make our life easier and that's why by default, dot Git directory is hidden. You do something in this directory or delete this whole it directory, you will lose your project history. In my company, one of my friend removed this git folder from his project and then he tried to use all it commands, but they don't work because.it folder is not available. Let me show you that. Here in our Git Bash, we are getting master in parenthesis, which means Git is tracking this folder. Now for removing Git directory, we can write RM for remove R for recursively F for force, and write dot Git. Hit Enter. C, Git is removed from this directory. That's why.it folder is important. Now let's initialize Git in our project again and for that, which command we use right, we use Git in it. See, again, we make our folder as Git repository. Git repository basically means Git is tracking this project history. Simple as that. Now in the next lesson, we will understand deeply how Git works. 9. How git really works?: So here we initialize our Git repository. Now let's see what are the pretty common day to day steps which developers do with it. We will understand this with one real life example. Imagine you are writing one storybook like Harry Potter. Now here, you don't want to directly write anything in your storybook, you work or write in another file. Now suppose you write the first chapter, first you check it, it is correct or not. If it is not correct, then you do changes or update that file, and if it is correct, only then you will take screenshot of that file and add it in your storybook. This is the workflow of Git also. Let me explain to you. Here in our Git repository, which is our storybook in example. Now we don't want to directly add our code because whatever we add in our Git repository, git will store it in history. We start working locally, which is our task track folder. Now suppose we create one file in that folder and we need to save it as history as our writing file. Now, at that time, remember, we verify it is okay or not before we save our story. Here we also do the same. We check, is it okay or not? Does we want to add or remove anything? This verification area is called a staging area. Now you might ask why we need this staging area. Without this staging area, whatever do in our local code, all code will store directly in our repository and we can't get chance to see what we change or what we remove in compared to previous code. That's why staging area is needed. Now after we add our code to the staging area, if we satisfy only then we will take screenshot of our code and store it in our Git repository. Now you might ask, how can we add our local code to staging area? Or how can we add our staging area code to the git history? The answer is very simple using Git commands. Suppose here we add one more file called index dot gs. We want to add this file in the staging area. Here we write command, Git add, and here we write our file name index dot js. Here, we can also add multiple files name. By using this command, we add our code in the staging area. One thing I want to make clear is staging area is not any folder. Staging area is just temporary memory which Git gives us. Many developers call staging area as index. Here we check our code is correct or not. If it is not correct, then we can update it or make it correct because we don't want to store code in history which has errors. Now, if we are ready to store this file in our history, then we take snapshot of the staging area and store it in Git history using Git gamtTh is short for message. Here we write our message which we want to store with this snapshot. In the future, we will know what we add in that Kummet. Commit means saving snapshot in Git history. For example, in the future, if we fix bugs or add new features, we make at for each Camt we add Commit message, which clearly says what we have done in that kat. By that, we can easily take a look to our code history. Make sure every time you commit anything, please add meaningful message. Each commit we do is stored with unique ID, date and time, author name, email, and our commit message. From these details, we can see which changes done by whom and when. Now suppose we add here another file called data dot TXT. Tell me what we have to do for store this new file in history. Right. First of all, we add our code to the staging area with Git add data dot TXT. And after that, we can take snapshot of this current staging area and store it in the Git repository by using Git Commit, adding data dot TxDFle in project. Here, I want to clear one thing is after committing the code from staging area to git repository, our staging area will not become empty. It will stay the same as we commit. If in future, we add or remove something in our local code and then add it in our staging area, then only those file updates which we modified. To quick recap for soring the code in our git history, first, we add our code to the staging area, and after that, if we satisfy with our current code, only then we will commit that code into our Git repository and Git repository will store all commands with its details. Simple as that. Don't worry if you get confused or you have a lot of questions, you will get your all answers as we move forward in this course, and I bet you will master Git like P. In this section, we will practically work with this Git workflow. 10. Exercise: Git Workflow: In the previous lesson, you learn the basic workflow. Now I want you draw the rough figure or rough workflow of gait with the two commands. Complete the one little exercise, but the condition is you can't watch the previous lesson. Try to remember it and then draw it on the paper or anywhere. If you draw on paper, then you can take photo and upload it in the Q&A section. I will try to check and reply to your submission. After completing this exercise, you can see the previous lesson and make sure your workflow is correct or not. It's a little game. Don't worry about lose or win. 11. Adding Files to Staging Area: Now, let me show you practically how can we add files to the stitching area. But first of all, we need to add file in our local code. I open up Task track folder in the VS code, and first of all, here, I create a new file called chapter one dot TXT. And here we write Hello. I'm creating here XD file, but you can create any file. Save this file. Now we want to add this pile to the staging area. In our Git base let me check the current status. If you want to clear the previous commands, then we can write here clear. It will clear all our previous commands. Let's check status with Git status. See here we get on branch, master, no commits yet. And we get one untracked file, which is chapter one dot TXT. And it is also giving us suggestion with Command Git add, file name. So we can write here, Git add, and here we can write chapter one dot TXT. If we want to add other files, then we can edit here with space, chapter two dot TXT, et cetera. We can also use here star dot TXT, which means add all files with TXT extension. Also, we can use here Git add period, which means add all files. Usually, many developers use this way, so we can use any of these commands. Here I use Git add chapter one dot TXT. Now here we don't see anything, but how can we check this file is added or not in the staging area? Can you tell me we just use it? We can use Git status. See here we get message changes to becomd and that's it. We add our file in the staging area. Now suppose we change something in our file. Here I add world in the second line. And save this file. Now let's check the status again, so get status and hit Enter. See now here we get message of modified. Currently, in our staging area, we have our previous edit code, which is the Chapter one file with only hello message. Now we change something in our local code, then we again need to add that changes to our staging area because to commit our code in Git history, we need to pass our code from staging area. Here, we can again write Git add Chapter one dot TXT. If we again check our status, then we don't get any pending modifications. That's how we add our code in the staging area. Also, I want to tell you if you like to create nodes, then you can start creating your nodes for gate commands. I will also add my nodes, but you can also use your own nodes. 12. Let's Commit your First File: Currently, we have our files in the staging area. Now let's commit our file to the it history. So in Git Bash, we write it commit. Here we can write for message, and in double codes, we add our Commit message. Let's say initial Commit. Now here we write sort description of our coat. But sometimes we want to add more lines of description. For example, we fix the burg, then we can add in the description, what was that burg, and we can't explain that in single line. For adding multiple lines of description, we type here only get coat. And hit Enter. This will open a default code editor which we added in our config. Do you remember? Great. Now here in the first line, we have to enter our short description and for long description, we have to write it in the new line. For this commit, we add short message like initial commit for long description, we can write, complete the first chapter. Do some modification in the story. I'm just writing random message for demo. Don't worry. I'm not going to create storybook here. Now you might ask, what about these lines? These lines are commons for explaining this description part, don't worry about that. Now let's save this file and close this file from here. Now if we back to our kit dash, see here we get one file changed and two insertion. Congratulations. We successfully done our first omit. To verify this, we can write kit stats and see here we get nothing to commit. Working tree clean, which simply means our working area code, staging area code, and the snapshot in the Git repository all are same. That's how we commit our code in git. You can see it is very simple and easy. 13. When Should You Commit: Now, a lot of developers do one mistake while using git. If they change something in the working area, they immediately state the change to the staging area, which is good, but they also commit all those small changes to the git repository, which is wrong. And also, some developers directly commit big changes to the git repository, and that is also wrong because we don't want to code for five days and then commit whole code. Is not the best way. You might ask, what is the best practice for coat? First of all, I want to tell you don't commit for every single change. That is useless because as we know, whatever we commit, it is going to store in the history in the history, if you get all small changes, then finding what you want from the history will become a lot hard. The Camt size should not too small or too big. Always commit when you think you reach a certain state which you want to record. Imagine committing code is like certain checkpoints which you want to make. If something goes wrong with your current implementation, then you can go to the previous checkpoint and restart your implementation. Do you remember the video game concept for checkpoints? As you successfully complete something hard, then you get the checkpoint which will ensure your game. Think like that. Another thing is each commit should represent a logically separate chain set. Don't mix things. Example, you are solving one bug, and you also found some styling improvements, then you don't have to commit both changes in one commit. You can do two separate commit, one for fixing the XYZ bug and then for improving the card styles. Also, another good practice for committees, you have to write a meaningful commit message because by Commit message, you will find your checkpoint in the history. So these are my tapes for coat. But at the end, you are the best judge of your situations. Don't think about, you will not make any mistakes. All of us will make some mistakes, but we can learn from our mistakes, right? Try to remember these tapes. It will help you in your gate journey. 14. Exercise for the Commit: Now it's time for little exercise for policing what we have learned in previous lessons. I want you to create a new file called chapter two dot TXT and write something in that file. After adding text, you have to commit that file to the kid repository. I know this is pretty easy and you can complete this exercise, go for it and then see the solution. So I hope you complete this exercise or you at least try to solve it. Now let's see the solution. I create here a new file Chapter two dot TXT. And here I simply add Learning Git is a fun experience. If you know how git works, do you agree with that? Let me know. Save this file, and here we return to our Git Bash, first, which status. See here we get one untracked file which is chapter two dot TXT. We have to first stage these changes, and then we can commit this. So we write Git add Chapter two dot TXT. Here, if you don't want to write a complete file name, then by writing half name, you can press Tab key, and it will return untracked or modified file names. That's little trick. After that, we simply Git commit, complete the Chapter two, and hit Enter. See here we make another commit, so you can see how simple and easy it is to commit code. 15. How to skip Staging area: Now, the common question which many it user has is, can we skip the staging area? The answer is yes. Not really skipping the staging area, but as we know for committing the code, we have to use these two commands. But in gait, we have another command, which is the combination of these two commands, but that is not a good practice. Do that only when you are 100% sure that you don't need to review your code because that is the purpose of staging area. Remember our storybook example, let me show you how can we skip the staging area. First of all, let me change something in Chapter one file. Let's start Chapter one. Save the changes, and back to Git Bash. Let's check status. See, we get one modified file. Now to commit these changes, as we know, we have to write two commands. First, we have to stage the file, and then we add Commit. But here we can directly write Gate commit A, which is for all modified changes and then for message. Or we can simply do that together by AM and after that, we can write our commit message, beginning of Chapter one. And hit Enter. See it is successfully committed to the gate. Let's verify that with git status. See, we get nothing to commit. This command will also add our all modifications in the staging area and also commit that code into git repository. But as I told you, only use this command if you are 100% sure. 99% time, we first stage our code and then we will commit it to the gate. 16. Removing files from areas: Now, suppose at this point we discover that we don't need Chapter two, or we want to delete Chapter two file. From VS code, I delete this file. Good. Now, let's check our status. Get status. See, here we can see we get deleted Chapter two file because we delete our file from the working directory, but still that file is available in the staging area. Let me show you. So here we write Gates files. This command will return all files which are available in the staging area. See, we get Chapter one and Chapter two. Now, as I told you, every time we do some changes, we have to add that changes in the staging area with add command. So here we write Gate, add Chapter two for add the changes, or we can say deletion of Chapter two file. Now let's check staging area files one more time. Get S files. Here S means list. See, here we get only Chapter one file. Now let's check our status by using Git status. See, here we get ready to commit. We can write Git comet for message, delete Chapter two. And done. We successfully deleted our Chapter two file from our local area and staging area both. Whatever we do, create a new file or delete the existing file, we have to first add those changes to the staging area, and then we can commit. Simple as that. Now you might ask, is there any shortcut or delete our file from working area and staging area and you guys correct. Yes, there is one command which do these two steps in single step. We can write get RM RM means remove. And here we add our file name, let's say chapter two dot TXT. Also, we can add here multiple file names and also we can remove all files by star dot TXT, which means remove all files with extension TXT. By using this command, we can remove our file from local area and staging area both. 17. How to ignore files in git [GitIgnore]: Now, sometimes in our project, we have one folder or file which we just created for our use. We don't want to put that in the Git repository. For example, if you are using node packages, you get node modules folder with thousands of file, so we don't want to add it in our Git repository. It will increase the size of our repository without any value. Other example is temporary files or log files which are not needed to add git repository. Let me tell you one story of my friend, me and my friend working in one corporate company. My friend, Harley, didn't know about gate. He just Githd and Git commit. One day, he committed his personal password file with the code. All team members are coming to his desk and tell him about his password and he don't know how all team members know his password. At that time, we have to ignore that file or we can also ignore the whole folder. Let me show you that practically. Here in our task track folder, we create a new folder called logs for storing debugging or application logs. Here we add new file called debug dot log in this file, we add some text. This is debugging log Save the changes. Here, if you pay little attention, when we create a new file in our folder, our file or folder highlighted with the green color at the right corner of the file name, we get U icon. Can you guess what is the meaning of this U? Write? U means untracked file. Basically, VSC telling us this file is not available in the staging area. Don't worry about that. I will explain you all these in the upcoming lessons. Now back to our Gitbsh here if we do git status, then we get untracked files. If we write here Git add, then this log folder will also add in our staging area and we don't want that. So how can we ignore these files? Very simple. Just in our project, we create a new file called dot Git Ignore. Make sure you write the same file name dot Git Ignore also this file should in our project root directory. In any other folder. Only then it will work. Basically, this Get ignore file tells Git which files or folder we want to ignore. Here, we want to ignore complete logs folder. We write logs slash. If we want to ignore node modules folder, then we write node underscore modules or if we want to ignore specific file, then we can also write logs slash debug dot log. We can do anything here. Now the moment we save this file, we can see that U icon is gone from our logs file. Also our folder and file name is in the gray color, which means get ignore all files in the logs folder. Let me show you one more time. I remove these lines and save it. See here we get U. And if we add again logs slash and save it, then ignore these files. Let's verify these with it status and see, we get only one on track pile, which is Gino, which we just created. Let's add it with Git add dot gitignore and then Git co ignore all log files, and hit Enter. Lovely. So that's how we can ignore files in Git. But remember, using this way, we can only ignore that file or folder, which are not already committed. In simple words, if we want to ignore our chapter one dot TXT file now, then we can't simply do that with Git Ignore file because our Chapter one file is already committed in git repository. So first, we have to remove our file from the staging area, and then we can ignore this file. Let me show you how can we do that? Here in our project folder, I create a new folder called, let's say, Ben. And inside this folder, we create a new file called backup dot Ben. Don't worry about these file names. It is just for demo. Here we add text like hello. Save this and see. Here we get untracked file icon. Now let me accidentally commit this file. So in our Git Bash, I write Git add period, which means all files and then Git commit testing But Bin file and we commit it. Now our file is already committed. Let's try to ignore this file. Let me show you which files are in the staging area by git As files. See here we can see Bupt Bin file is already here. So how can we remove this file from staging area? In the previous lesson, we seen Git RM for remove and we add our file name, let's say, been slash backup dot Ben. But by using this command, it remove this file from the staging area, but also from the local area. But here, we want this file in local or in our working area. So for getting help, we write H for help. Here we can see we have option dash dash cast, which will only remove from the index. Index means staging area. We write Git, RM, dacast and we also have to add here R for recursive removal because we want to remove all files from the bin directory. If we don't write here R, then we get error. And we add Bin directory and our Bin folder is removed from staging area. Let's check also our staging area piles with it As files. See, Bin file is removed from here and let's check our status, it status here we get one deleted file, but also we get track file from Bin. Here, we have to add Ben directory in our dot Getting nor file. Save this and see, here we get read the icon, which means deleted. Let's check status again. See, here we get one deleted file and also we get ti no file modified because we added bin directory in our GTI nor file. Let's commit these changes and commit, remove the bin directory that accidentally committed. Now let me modify something in the Bin file. Save this and see we don't get any modification message, but the gitignore file stays as modified. Can you tell me why? Let's check this with status? See, here we get modified gitignore file because we forgot to add our GetI no changes to the staging area. Don't worry, it happens many times with me. So here we simply stage the changes using Git add period. And then Git commit ignoring win directory and done. So you can see how hard to ignore already committed files. So the best practice for Git is, we will add Git Ignore file at the very beginning. So head over to github.com slash GitHub, slash Git Ignore. Here we get all templates for the Getting no files. For example, if you are working with react application, then you can search here node. And here we get a template for all application which use node. Simply copy this template and paste it in your Gating nerve file. Simple as that. 18. Viewing changes between areas: Now, let me ask you one question. How can we see the changes which we make using it? You might say we can use Git status command, and you are correct. But this command will only return the file name. What if we want to see what we change inside our file? Let me show you. In our Chapter one file, I remove these three lines and add here, this is the starting of our story. Save this file and we get here for modification. Now let me show you how you can use another it command, which is itive for differentiate. See, this is looking very complex to see the exchanges in the terminal. And if you are seeing this first time, then you can broke your screen. But let me try to explain you. Here we can see it differentiate between A Chapter one file and B Chapter one file, which means it is comparing same file with a different version. After that, we have index and some metadata, which is really don't matter for us. After that, we get these two lines, changes in the first file indicate with the minus and changes in the second file indicate with plus. Don't worry about this. Basically, it is showing we remove these three red lines and add this one green line. Simple as that. Now, as I told you, watching the changes in the terminal is not very easy. Let me explain to you how can we use our code editor to watch these changes? First of all, we have to tell Kat, we want to use VS code as the TIF tool. DIF tools means differentiate tool. We write Kit, config dash global. We are setting it as global, so we don't have to configure for each project. After that, add div dot tool and we set that to the VS code. With this command, we are just giving name of our DIV tool, which is VSCode. Don't worry, this configuration is only one time process. Now we need to tell Git how to launch VS code. We again write Git config Global DIV tool. Scode dot CMD. Double codes. Now in my machine, I add code as a VS code path, so I can run it from any directory. If you don't add it to your path, don't worry, I will show you in just a minute. Here we add weight, which will tell our terminal to wait. And after that, we use D, which is for differentiate or comparing file, and then we have two more arguments, which is dollar local with all capital letter space dollar remote. These are the placeholders for the old copy and new copy of our file. Now let's make sure that we added this command in our config or not. So we can see all our config settings by Git config, Global E, and hit Enter. Here we can see all our configuration. See here our dollar local and dollar remote is not added. You can add them. Save this file, enclose this Git config file. Now back to Git Bash. If we want to see changes in the VS code, instead of writing Git Dev we write Git DV tool. This will compare what we have in the working directory and what we have in the staging area. And it is asking for launching VSCode. Write yes and enter. See, here we get our Chapter one file. Now, if you don't understand changes in single file, we can split it into two files. In the right corner, we have three dots here, we have to D selacg the inline view. If you still don't get side by side files, then you have to press Control plus B or Command plus B to close this Explorer panel. Here, we can clearly see what we have changed, which is we remove these three lines and we add this green line. This is our old stage code and we done changes in this local code. Now, if in the future, you want to see the changes, then you have to just write Git Div tool. Now you might ask, how can we see changes between staging area code and commit code? We close this comparison view and in our Git dash, we have to simply write Git Div tool, dash dash stage, and hit enter. Here we don't get anything. Can you tell me why? Because our staging area code is the same as our commit code. We have to stage our new changes. We write Git add dot. Now we run again Git D tool. Dash dash stage. Launch via code, write yes and see, here we get changes between stage area code and Commit code. To summarize this lesson, if we want to see the changes between our local code and stage code, then we use it Diff tool, and if we want to see the changes between stagecde and Commit code, then we use it Di tool, dest as staged. You are continuously watching this course, then in my suggestion, take ten to 15 minutes break from your screen. Listen some music or spend some time with your family. Take care of your eyes and see you in the next lesson. 19. Shortcut for Status: Now currently, if we want to see the current status, then we write git status. But these command return very long status. Now there is another shortcut way to get status. For that, we create a new file, Chapter two dot txD and enter some text in it. Also we change something in the Chapter one file. Now back to our Git dash and instead of writing git status, we write git status a for short, and hit Enter. See, here we get little status. This is much easier to see. Now here we get two columns, left column and right column. This left column represent the staging area and the second column represent our working directory or local area. Currently, we modified our Chapter one file in the staging area and also in the working area. That's why we get here both M, M for modified. Let me explain to you in simple way. Our Chapter one file in the staging area is different from what we have Chapter one file in our commit. That's why we get here first. And our current working area file is also modified from what we have in our staging area. That's why we have here also. Let me show that practically. Here, we write Git add Chapter one dot TXT, if we again write here, git status has, see, here we don't get from the right column, which means our working code is the same as staged code. And if we commit file one, then this will also remove from here. Now you might ask why we get here double question mark? Because we create a new file. That's why we get here both question mark. Let's add Chapter two file in the staging area. Git add Chapter two TXT. Then we get status again. C, here we get A, which means added. That's how we can quickly see the status. If you like to see whole status, then you can use Git status. If you like this approach, then you can use this shortcut. Choice is yours, it's totally up to you. 20. Viewing commit history: Now, currently, we have committed code many times. What if we want to see all that commits? So for that, here we write it, log, and hit Enter. So here we get all Camtes in order of lettuce to the earlier. At the very beginning, we get our last amit each commit has its unique ID that's auto generated by it. When we want to access that mite or we want to see what is inside that amit then by using this unique ID, we can access that specific commit. Now next, we get headpoint to master. You might ask what is headpoint to master. Don't worry about that. I will explain you about this in the upcoming sections. For now just know this git master is a default branch name. Branch is an area which we created for our own use and this head is telling us we are currently working on this master branch. Don't worry, I will explain you that in very detail in the upcoming sections. Now after that, we get author name and here we get author email. As we get date and time on which this commit happen. Here at the bottom, we get here our commit message. By using this commit message, we know what is inside this commit, and that's why I tell you to write meaningful commit message, which you and your colleague can understand. Now currently, we get only three or four commit details because these commits are divided in pages. If we want to see other pages, then press space. See, here we get our other commits. Now to quit, we just need to press Q. Now this log command has very interesting options. Here we can write Git log, dash dash one line. This will return Commit list in one line. So here we get its unique ID, and only we get here short description or Commit message. We have another option, which is Git log dash dash one line, dass reverse. And see, here we get our commit list in reverse order, which is from the first commit to the latest commit. Now the log command is powerful command for browsing history. We will use it a lot in the upcoming section. In fact, we have complete section for browsing our code history. For now, let's ticks to the basic. 21. Unstagging the files: Now currently, if I check our status, then here we get modified for Chapter one file, and also we add new file Chapter two. Now, as I told you before, we should never commit two different tasks in single commit. So we should first commit our Chapter two file, and then we should commit our modified Chapter one file. For that, here we first unstage the Chapter one file. So we write, get, restore das stage and here we write our file name, chapter one dot THD. Here, we can also write multiple file names, or we can write pattern, or we can even write period, which will unstage all changes of our code. For now, here, we only want to unstage chapter one dot THD file. Now, if we check again the status here we get red, which means it modified in the local or working area. Now, it's important for you to understand how this restore command really works. The restore command basically takes the copy from the next environment. Don't get confused. Let me explain to you in simple way. So when we write git restore stage, chapter one dot thD basically, you are saying we want to unstage the chapter one THD file. Git takes a copy of the next environment. What is the next environment after stage environment? Remember that figure. Commit is the next environment after stage environment. So it simply takes copy of our Chapter one file from the last command and simply add that in the staging area. But our working area has that changes. Indirectly, we unstage our Chapter one file. Now, if I ask you a question, what if we run this command, Get restore stage Chapter two dot TXT. So as I told you, this command will take the copy from the next environment, which is the Commit environment. But our Chapter two file is not available in the last commit because we just created our Chapter two file, and that's why we never commit this file. So this command will remove our Chapter two file from the staging area. Let's verify these I status. See, here we get two question marks, which means our file is track. So to quickly summarize, if you accidentally added changes to the staging area that you don't want to include in the next commit, then git restore d stage helps you to move those changes back to your working directory. And by that, it is giving you the chance to re evaluate or make further modifications before committing them. That's how we unstage our files. 22. Discarding Changes in local files: Now, sometimes we do some changes in our working directory, and we want to throw away that changes. In simple words, we want to restore our local files with the staged area files. So here we have modified our Chapter one file. Suppose we want to undo these modifications so we can restore this local Chapter one file with our staging area Chapter one file. For that, we use the same command which is Git restore. And here we write our file name which is chapter one dot THD. Now, previously, we write command, get restored as staged, chapter one dot TXT, which takes a copy from the next environment, which is commit. Because in this command, we mention stage as our current environment using this dash as staged. Now if we remove staged from this command, can you guess what is the current environment? Currently, we are at the working environment. This command will take copy from next environment, and what is the next environment? It will take copy from the staging environment. We can also write this command like this. Get, restore multiple files. Also we can restore all files with period. Our file gets restored from the staging area. We can verify it by Git status. See, here we get only Chapter two file. But why Git don't restore this file? Simply because Git don't have its previous copy in the staging area. Git leaves it as it is. Now you might ask, how can we remove all untracked files? For that, we have to type gate clean command. See, here we get one error. It is telling us required force, so we can write gate cleang for quick help. Here, we can see for force remove, we have to use F and we can clean whole directory. We used also. We write gate clean f, D. Make sure by this command all unstaged files removed from our working area, and we can't restore those files. So make sure which piles you are cleaning. Now, let's verify status. See, here we don't get anything, which means all files get restored. 23. Restoring to earlier version: So now we know that once it starts to track any file, it stores every version of that file in history. So if by mistake, we messed up with our file and also commit it, then we can restore our file from the git history. So to demonstrate that, first, we remove our Chapter one file, and then we will restore that file from Git repository. So do you remember which command we use for removing file from working directory and also from the staging area? Right, we use Git RM, chapter one dot TXT. Let's check our status. See here in the staging area, we get deleted Chapter one file. Now, let's commit these changes. So Gitt delete, Chapter one file for restoring. Let's also check this in the VS code. See, our Chapter one file is deleted. Now suppose we want to get that file back. So let's restore this file from the Git repository or Git history. Let's check our history with Gitlog one line. Here, we want to restore our Chapter one file from the second last commit, which we did. So for that, we write git restore H for quick help. Here we can see after Restore, we can add multiple options. And after that, we have to mention our source. Source basically means commit, and after that, we have to mention our file path. Now let me again check history, Git log one line. Now we can write Git, restored source equals to here we write our commit ID from which we want to restore. We write here this commit ID. If we want to restore file from another commit history, then we have to write that commit ID and after that, we write our filename, chapter one dot TXT. Now let's check the status. See, here we get untracked file and if we check it in the VS code, see, here we again get our Chapter one file. That's how we restore file from the commit history. 24. Basic Git Operations in VS Code: So till now in this section, we perform each task with a command line, and I hope it clear your doubts about basic Git operations. Now in our VS code, we can also perform some basic operations for Git. So here we go to the source control panel, and here we get this type of interface. In this changes list, we get the list of changes. Here, we get the same results which we get from git status command. Here we have one change, which is in this Chapter one file. If we click on this file, here we can compare our current code with the previous code. Also, we can see here this file is a new untracked file. Now to stage this file, we can do that very easily. Just we need to click on this plus button. See, here we get stage changes. We can also unstage this file very easily. Just click on this minus button. Now we have local changes in our working directory. Let's stage these changes. Now you might ask, can we commit from VS code? And the answer is yes. So here we write our commit message. Let's add again, Chapter one file from VS code. Now let's click on this Commit, and we successfully commit this code. Now let me show you something really cool. Let's go to the explorer panel, and from this bottom, here we get timeline. Let me zoom in a little bit. See here we get the history of our current open file. Here we get all changes we have made in our code. If we want to see history of kit, then we use here this filter option. Simply remove check from the local history and here we get history of this currently open file, which is Chapter one. We can view it by clicking on it. That's how we can use our VS code for simple operations. Now you might ask, why don't I show you this way of doing basic operations? Why I teach command line? Just imagine if I directly show you this lesson without explaining all previous commands, then you will definitely confused a lot and you will never understand the basic of git. That's why I first teach you the command line. Now you definitely know what you are doing in your source control panel. 25. Introduction to Github Desktop: Now, let me show you the graphical user interface of using Git, which is Github Dktop. This is one of the best and beginner friendly GI tool for using Git. Another popular tool is Git Kraken, but it is little complex for beginners. So in this course, we will learn Github desktop, which is beginner friendly and also I will show you Git Kraken, which is my recommendation. So head over to desktop.github.com and download the Github Dktop application and install it. Here how it looks when we first time open this application. It is asking to log in with Github account, or if you don't have Gitub account, then you can create a new account for free. I already have Github account, so I quickly log in with that. Here it is asking for my name and email. Make sure you double check these details. See here I can change my email also and confirm. Now here, we can create a new Git repository and also we can open Git repository, and we can also clone existing repository. For now, don't worry about cloning. We will see that in the upcoming section. So here we open Git repository. We go to the project folder and select our task track project. See, here we get this type of interface. If we change something in our file, let's add some text. I am writing this Chapter one for introduction. And save the changes. Now, if we change anything in our file in our Github desktop application, here we get those changes. From this setting icon, we can select split type. Now, here's one thing about this application. This application will directly commit our code. If we don't want to commit this file, then we can uncheck this file from this list. This list is staging area. Okay. Now let's see how to commit our code to Git. So here we write our sort description. You can see by default, it is showing Commit messagon we can write Update Chapter one for tasting Github desktop. And if we want to write wrong description, then we can also write it here. And after that for amit we simply click on this Kammit to our branch which is master. And it's done. We successfully commit our code. Now we can also see the history of our amides from this tab. Here, we get the list of all our amides. By selecting each amid, we can see its file content. So you can see iTu desktop application makes Git so simple. If you like to use Command line or VS code, or you like iTub desktop, all are fine. But as you see with command line, we can control more on Git. We can do variety of tasks by kit commands. Honestly, I like to use kit commands and VS code, but the choice is yours. You can choose tool in which you feel confident. It's totally up to you. 26. Introduction to GitKraken: So in the previous lesson, we see our first GI tool, GitHub Desktop. We have another tool which is kit Kraken, which is little complex, but once you understand and familiar with kit, then you will use this tool more. Also, Kit Kraken has more features than GitHub desktop application. I personally like to use Kit Kraken. You will see the reason in upcoming sections. Let's also install tKracon in our system. Head over to kitcracon.com, and here we get a Download button. Simply click on that and it will start Download. After completing the download, we open a setup and we can easily install Git Kraken. Now when we open Git Kraken for the first time, here we get let's open a repository option and we can sign in using Github. For now, let's open a repository. See, it automatically fez the details of my Git account because I just login in the previous Github desktop lesson. So I can film this. Here we get this type of interface. We can open the repository or we can clone repository from Internet, or we can create a new repository. Currently, we want to open repository from local, so we go to the open repository and open our current project. See this is how our repository looks. This is a little bit complex for beginners because this is so much cluttered. I feel the same when I use Git kraken for the first time. But trust me, as we become familiar with Git, this all makes super easy. Here is all comets and we can see more details about that Camt by selecting them and at the right side, we get the details. See here we get commit ID, commit message. After that, we get details about author who commit this date and time and below that, we get a list of files which we delete, add or modified. Basically, we get changes which we done in this commit. Here, we can short these files and also we can see the files in tree folder structure. When we click on that file, see, here we get the file and we can see this file in the split mode using this icon. For now, that's all about it Kraken. Don't worry. We will see Git Kraken in more details in the upcoming sections. See you in the next section. 27. Section 03 Watching Code History: Welcome to the third section of the ultimate it course. In this section, we will see how can we browse our Cami history in more detail. First, we will see how can we see all commits, filter the commits by author names, dates, commit message. Also, we will see how can we set shortcut commands for long commands? Next, we will see specific amides, compare two amides, return to the specific commit, detecting bug commit, blames, giving tag to the gummit and much more things. I know you are excited, so let's start this section. 28. Cloning local project: Now for browsing the history, we need one project in which we have few commits. So below this video, you get the resources folder, and in that folder, I added Task track project which I created in SDML and CSS. Let me show you how can you clone any existing Git project in your machine. So pun resources folder, and here we have course Task track Zip. We can unzip this we can simply copy this folder from here and paste it in our project's folder. Now we can start using this project. Simple as that. 29. Exploring Log Command in Details: First of all, let's open our project in Git Bash. In the previous section we seen for watching the history of our Git project, we use Git clock command. This command will give us all commit details about each commit like Commit has author details, date and time, and commit message. Also, we get these commits in order, which means first we get the last commit and at the end, we get our first commit. We have more than one pages, then we can press space or we can move up and down using arrow keys. For quit from this command, we press Q. Now, do you remember by which command we get this log in less details? Right, we can write here Git log dash one line. See here we get only little has and commit message. We have already seen these two commands. Now let's see this log command in more details. What if we want to see the files change in each command? For example, in the second command, which files get modified or what we change in the last command? For that, we have to simply write datat at the end of our log command. This tat means statistics. See, here we get one file changed and we get that changed by name here. After that, we can see 16 insertion. Similarly, we have these details for each comet. Now, if you get confused by a lot of details, then you can also do this. Add here one line and see here we get a little less details about Comet. Here we only get which file changes and the number of lines we change. But what if we need to see which line we add or remove or update? Don't worry, it is really simple. We write gate, log, one line, Despatch. See here we get the lines in green, which we added in the file. And if we remove something from this file, then we get those lines in red. By these commands, we can see what happened in our project very quickly. Now to quit this, we have to hit space multiple times, and when we get and we press Q. 30. Filtering the History: Now let's see how can we filter our Commit history and only get the specific details which we want to see. It is the same as we filter products on Amazon. And also, it is also super fun to do. Let me show you. So first, we see how can we filter our amites by using author name. So here we write gate, log, one line, author equals to here we write our author name. If the author name has space in its name, then you have to wrap that name in the double codes. Otherwise, it get confused. Here, this author name is as sensitive, you have to write the exact same name. And if you want to ignore sensitive, then at the end, simply write I and get ignore sensitive. See here we get gametes done by name Mt Patel. How can we more filter these mites? Right, we can filter amides by using dates. So Git log, dash one line, dash dash B four equals to here, we have to write our date in double codes like this. 2024 our month 01-30. See, here we get all amides before this date. Now sometimes when we work on big projects, we like to see Camids which committed after a specific date. So we have here after, and here we pass our date in the same format. We can also pass strings like yesterday, two days ago, one week ago, one year ago, et cetera. This is very useful. I use this a lot why I take one or two days leave. Now sometimes we want to filter from our commit message. For example, so only those commits, which has word task in the commit message. We write it, log, dash one line, dash grab equals to in double codes, we write task. This is also case sensitive, so make sure you write proper word. See, here we get kmtes which commit message has this task word, and for ignoring the case sensitive, what we will add write, we add here I. C, here we get kmtes which has task word in the commit message. Now sometimes we want to find specific commit which add or remove the function or variable. For example, we are working on Todos project, we want to know when we add Add todos function or when we remove it. So we can do something like this. Git log, dash one line, capitals here in double codes, we have to write our function name, addTds. Currently, in this project, we don't have this function. So I search here. See, here we get the commits. Now imagine sometimes we want to see only last three commit or five comets. Then we can write git log, dash one line, five. See, here we get last five comets. Also, sometimes we need to see the history of specific file. For example, we want to see index dot STMLFleHtory, when this file added or removed. Then we can do something like this. Git log, dash one line. Index dot html, and see here we can see the history. Now, if your filename is already registered in the Git library like you file log, then here, you can separate this command and file name by using double dash. See, here we get the same result. Now, let me ask you one question. What if in this command, we want to see the changes inside of this file? Right. We have to write dash dash page, but we have to write page before this double dash because this double dash separate the command from the file name and see here we get the file changes. 31. Setting Alias for Commands: Now, sometimes we have to run several Git commands which we use very frequently, but they are little long or they are hard to remember. We can set shortcut for those commands. For example, we frequently running this Git log dash one line command. Let's set shortcut or in git terms, setting an lias.Ellas simply means another name. We write Git config dash global Alias, period. Here, we have to write our shortcut name for this command. So we write lg for log. Make sure you use meaningful names because at the end of the day, you have to remember the shortcut names, and after that, we have to write our original command, which is log one line. Here, we have to wrap our command with double codes because we have space in between and hit Enter. Now, let's verify we set it successfully or not. So we write it configs global E, and it will open our Config file in our default code editor. See, at the end, we get our Alias lg to log one line. You want to update as or remove anything, then you can do that from here. For now, we don't want to change anything, so let's close this file. Now, let's use our alias. Write t lg, and see here we get our command output, so that's how we can set as or shortcuts to save our time and memory because we don't need to remember whole long command. Now for the rest of this course, I don't use this alias because if someone join from the middle of this course, then they will not understand how I am using alias. But you can definitely use that for your practice. It's totally up to you. 32. View Specific Commit in Details: Till now we have seen how can we see all commits. But sometimes we want to see the specific details like specific commit Bits Commit has. For that, we can write Git, show, and here we write our commit reference. See here we get the details about this specific commit. Here we can see we have only one file changed and at the bottom, we have the changes. Now, if we want to get the last recent commit, then we can write here, get how head with all capital letters. If we want to go more down in the Commit list without writing the commit then we can write here till and we can write here number, let's say two. So Git first find the head and then move two steps down and give us details about this commit. You can see it is very easy and simple. Now, if we want to see the file name which are changed in our specific commit, then here we have to write Git, show, head till two, name only. See, here we have only one file which change in this commit. Now let me give you one more situation. What if we want to see the full content of the specific file in specific commit. So we get our previous command and simply add here column. And here we write our file path like file dot TXT, or if we have folder, then we can write Css detyle dot css. See here we get the full content of the specific file in our last third command. That's how we can see the specific commit in more details. Now in the next lesson, we will see how can we compare to commands. 33. How to compare two commits: So when we need to compare A two commits to see what added, removed, or changed in our code. So for that, we will use Git di command. This command will tell us the difference between our working directory and last commit. Currently, we don't have any difference. That's why we don't get anything. Here, we can also compare two specific commits. Let's say head till two space head. Here at both places, we can also add commit reference. See, it has multiple files and multiple changes. Now, if we want to see only one specific file changes between these commits, then what we will do? Simply, at the end of this command, we add our filename, CSS style dot CSS. Now in the next lesson, we will see how can we restore our code to the specific commit? Oh 34. Returning to Specific Version: Now, sometimes we want to restore our code to one of the specific mit. For example, this omit. We want to make our code exactly whatever we committed in this omit. So we write Git, check out, and here we add our omit reference. See, here we switch to this met. But here we also get this warning, which is warning us about the detached head state. Now many developers confused a lot about the state, but it is not very hard. Let me explain to you. Here we have our commit structure. These are the number of comets. This is the first commet and at the very right, we have last met. Here we can see all these commits are linked with its previous commit. Now as we can see in our Git Bash, currently, we are at our master branch. Branch is the little advanced topic in git. We will see that in the upcoming section. For now, just understand branch is like line which developers create for individual project work. Like if manager give you to work on one login form, as a developer, you create a new branch for working on the login form. Master or main is a default branch in git. Here, this master is a reference which represent our last kmt. Now, every time we commit a new code, this master move to the last kat. Now as we know in Git, we can create multiple branches. In that case, how git know currently on which branch we are working. To solve this, we have another reference called head. Head points out the current branch on which we are working. We have seen this before. Now as we add new commits, this head and master will also move forward with our latest mite. Now when we do check out to the specific commit, then our head reference move to that commit. And this is the detached head state. Ideally, when we are in the detached head state, at that time, we should not commit a new code there. If we create a new commit, then that met will add here. Now, at some point, when we move our head to the master, then this comet can't access by any other comets. Git declare this commit as dead commit, and after some time, it will automatically remove this commit from its record. So it's better to do not commit the code when we are in the detached head state. We can always look our code and experiment with our code. Now, as we can see here our Git pass change. Previously, we get here master. But when we check out to the specific command, then here we get the commit hash of our checkout commit. Now at the current point, if we log all our commands by using Git log one line, here, we only get comets which are committed before that specific comet. Other comets are invisible at this point. Don't worry, those other comets are not deleted. It is just invisible. Also, our head reference is here. Now, to see those invisible comets, we have to add here one more variable, which is all. See here we get all our comets and we can see our master reference is here and our head reference is here. Now to move our head back to the main or master reference, we can write here Gate, checkout master, and see, we move to master and see our head point to master. And now we get all comads. Using this way, we can see our previous code in our code editor or in file explorer. And that's why checkout command is important. 35. Detecting the bugged commit Git Bisect: Now imagine if something happen in our code and we get nnn Berg in our application, then how can we identify in which command bug happen? One solution is we can check all these commands one by one using checkout command, but this will take a lot of time. In git, we have one command for quickly identify the bug command, which is by using Git by set. For start this process, we have to write gate by set, start, and hit Enter. Here we can see our Gitbsh is in bisecting mode. Now, after starting bisect process, we have to first mark our current commit as bad kommt. If you want to know which is the current active mite, then we can see that from here, which is our master commit. Here we are marking this as bad coat because we encounter bug in this coat. Git bisect bad. Also, if you want to mark another met as bad kit, then at the end, we have to write its commit reference. I know this is a little confusing, but in just a minute, you will understand this. Now, after that, we have to tell gait, which is the last good met we know. For example, till this met, we know our application has no bug. Then we have to make this at as good at. So we write gate, bisect good, and here we enter our Comite reference. Now let's simply log our comets, see, now our head move to the half of our comets. Now here is the logical part of the bisec command. Imagine we have these ten comets. We mark our last comet as the bad comet, and our first comet is the good met. The moment we set our first amet as good KumtO head move to the middle point between good and bad. Now, because our head is on this at, our current working code will be replaced by this amet code. We can check our application at this at. If we have bug in this coat, then we will mark this at as bad. If we don't have bug in this at, then we will mark this ate as good kamte. For example, we find this amet has no issue. So we will mark this met as good using Git BSc good. Now as we mark this ate as good, our head move to the middle point between our bad kmt and good kat. Now, we again check our code. If it is good, then we mark it as a good. And if we find this kamete as bad, then we mark it as a bad comet. This process will continue to narrow down the list, and at then we get the comet which cause burg. That's the whole idea of the bisec command. So in our commit, we can check our code in the Vas code and see if it has BG or not. Imagine we found this commit has bug. Then here we mark get by sec bad. Now, again, we will check our list, see how is moved to this commit. We again check our code and imagine this commit has no burg. Then we will make it good using Git Biseccd. See, here we get this commit as the one which added the burg in our application. So that's how bisec command works. It might look a little bit confusing, but if you use this command one time, then after that, you will understand it so easily. Now here we can see we are still in the bisecting mode. To exit this mode, we have to write get bisect reset and see we are back to our master command. That's how we can identify bugs in the metes without checking all metes in the row. 36. Getting the List of Contributors: Now, if sometimes we want to know how many commits happen by users to know the contribution. So for that, we write Git short log. See, here we get user name and the number of commits by this user. And also, we get the summary of the commit messages. Here in this project, I'm the only contributor. So that's why it is showing only my name. Now we can even modify this command by using more options. Here, we write it short log, H for quick help. And see here we get all other options. For example, we can write N or dash dash numbered for shorting out the output by number of commits done by each user. Now, if we have long list of commits, then for C each contributor, we have to scroll. After this N, we can write dash for ignore the summary commit message. See here we get only the number of comas and user name. Now in the next lesson, we will see the history of the file. 37. Browsing History of the File: Now we have seen this command before. I'm just adding it here because it is the part of browsing the history section. So as we know, for watching the history, we can write it, log, and for watching the history of particular file, we can write the file name which is index dot HTML. See here we get the list of cods in which this file changed. If we want to narrow down this list, then we can use here variable dash one line. See, now it's readable. Now, what if we want to see the changes happen in this file? We can use here datat for getting the statistic, or we can say number of changes in this file. See, in the first commit we have 150 changes. Similarly, we have 35 changes here in which 32 insertion and three deletion. Now if we want to see the actual changes in the file, then what we will do right at the place of this ds dat, we write dispatch. You can see Git commands are not hard. It is just a matter of practice, and I have trust on you. After practicing this git command in one project, you can use them in any other project without getting worried. 38. See Author of Each Line [Git Blame]: Now, sometimes in our project file, we want to know who is the author of any particular line. It happens in my project, a new developer join my team and he writes a very bad code. If I ask anyone who write this code, then no one will answer, and I already know who writes this code. So I always ask that developer to check who writes this code. I was not making fun of that developer at the beginning, we are all at that level. There is nothing wrong about it. No one becomes the perfect at first day of coding. Is a journey which takes long time. Back to our Git example, if we want to know the author of particular line, then we can write git blame, and here we write our file name or path. See, here we get all content of the file line by line with the details. Here, first we get to commit reference in which this line return. Then we get the authorame and also we get the date and time. Now, if sometimes our file has lots of lines and we want to know only one specific line, then we can write L here, and then we write that line number, the end of the line number. Let's say we want to see only three and four. Then here we write 34. If we want to see line three, four and five, then we write 35. See here we only get three, four, and fifth line. So that you can use blame command to know the author of each line. Now in the next lesson, we will see how can we give tag to commit. 39. Marking Commits with Tags: Now, imagine currently this aid is ready to launch in the production, or we want to mark this commit code as the version 1.0. But I already give this at version 1.0. I have to give here version 1.0 0.1. So to give a version name to the med is called as giving tags in Git. Let's mark this amet as the version 1.0 0.1. Here we write git tag, version 1.01. Here we can write our commit reference and here we don't add any commit reference, then by default, get to give this tag to our current commit, which is the master commit. Now if we log our commits, see, here we get tag version 1.01 after this commit reference. Now if we want to check out our code to this commit, then we don't need to write this commit reference. We can simply use Git, check out version 1.0. Same as we use this commit ID, we can use this tag, version 1.0. Now suppose I want to see all tags which I gave to this project. Then we simply write Git tag and see here we get all tags which we assign. Now suppose we add this tag by mystically, and now we want to remove this tag. So we simply write git tag D, we write our tag name, which is version 1.01. Now we can see tag is removed from the list. Here we have this version 1.0 tag, which we call as lightweight tag, which means we give our amid just a reference as version 1.0. Now in gait, we have also annotated tag. Now you might ask what is annotated tags? So annotated tag is used to add more details like tagger name, date and time and commit message. In simple words, with annotated tags, we can simply add more details with our tags. Here is the command for annotated tags. We write gate tag A for annotated version 1.01 M, which stands for message. And in the double codes, we can enter our message like release version 1.01. Know this message is not very useful, but I'm just showing you if you want to add message with this annotated tag, then you can do this way. Now, if we write it tag, then we get two tags. If you want to see text message, then we have to write Git tag N. See, here we get the tag messages. If our tag is lightweight tag, then we get that commit message as the tag message. So don't confuse about that. Now if we see our version 1.01 with it Show version 1.01 command, then see here at the top, we also get the tagger details like name, email, date and time on which we give this tag and tag message. That's how we use tags to mark versions. 40. Commit History in Github Desktop: So let's see the history of our CIDs in the Github Extra application. So let's open this section project in Github Extra application. Go to the file, add Local repository. And here we see the path of our folder. And simply select that folder. In the previous lesson, we see how to see changes in the Github desktop application. Now we will see how we browse the commit history using this application. So here we have list of commits at the left side and also we get here our text and here at the top, we get Commit message, author name, and Commit reference. Now here we get the list of changed file. If we click on them, then we get the changes here. Also, we can change our view from this setting now here we can see we have very few options to browse our commit history. For example, we can't filter our commits, can't search for a specific function or variable and a lot extra things. Github desktop application has simple user interface, but it is not the best for using Git. This is one article which I like. In that article, I see developers are saying they only like Github desktop application when they are beginners of Git. But as they learn Git in more details, they don't really like Github desktop application. I'm slightly agree with that, but that doesn't mean you have to uninstall Github desktop application. You can use Github destra Publication if you are comfortable. It's totally up to you. 41. Browsing History in VS Code & GitKraken: Now let's see how we can browse history using our favorite code editor VS code. So as we have seen in the previous section, here we can see our changes in the code. But what if we want to see the history of our mets and also the list of comets. We can see it in the VS code, but we can see that using one extension called Gitans. This is one of the most popular Git extension in VSCode, and the funny part is this extension is by Git Kraken. You use Git Kraken instead of Github desktop, then you will see the same interface as we see in this extension. See here we get two more options at left side for git lens. Open this first one let me zoom out a little bit, close this, also close this. Now in this, we have many options. See, first, we have Commit graph. This is one of the popular way to view omits history. Here, we can see, we get a list of our commits and here we can also get the text which we give to the commits. Next, we have Commit message, author name, changes in the files, time, and commit reference. At the top, we get also the search bar for searching the comets. If we search here something, then it will highlight only those ads, which commit message has this word. Now for more search filter, we have little drop down here. First, we get my changes, which will show us only those comets which are committed by you. Next, we have message for searching the commit message. Next, we have author by which we can search commits by author name. After that, we have commit SHA in which we can search commits by commit reference. Next, we can also search specific file. For example, we write here index dot HTML. See, here we get only those commits highlighted. And last, we have change by which we can search functions or variables. Now if we select one command at the right side, we can see more details about this commit. At the top, we get the commit reference. Here, we get out our name, time, and also commit message. Now at the bottom, we have section for changed file, and here we get the number of files added, which is zero, number of files change, which is one, and number of files removed, which is zero. And below that, we get the list of files which are added, changed, or removed. If we select that file, then we can see the difference which we make in that file. Very useful. Now, after the commit graphs, we have more options. But as we can see, there are many things which we cannot see here, and that's why Git commands are essential to learn. It's totally up to you which you want to learn. In my humble opinion, learning both is more beneficial for you. Let me show you how can we browse history using Git Kraken application. We open our projects folder, which we want to open and simply right click here and open with Git Kraken. Here is the interface of Git Kraken application. It is very similar to the Git lens extension. Here we get the list of commits we did at the top, we have also search options where we can search by Commit message. Here we can also filter commits by the authors. Now as we select the commit, we get the commit details at the right side. Here, we get the Commit reference, commit message, author, date and time, and modified files. If we select File, then we get here the changes. We can also change the view type to split. At the top, we can also blame for see the commit author. At the right side, we have also tree folder structure, and we can also view all our projects file. So you can see by using it Kraken application, we can easily browse our history. We use Git lens, then we don't get that much space. It is very congested. So use whatever you like to use, it's totally up to you. Now in the next section, we will see the most important topic of git, which is branches, see you in the next section. 42. Section 04 Working with Branches: Welcome to the fourth section of the ultimate Git course. In this section, we are going to learn all about branches, how to create branches, view them, compare to branches, how to merge them, resolving conflicts, and much, much more things. This is one of the most important topic of Git. I know you are excited about this, so let's start this section. 43. What is Branch: Now, as we know, our task track project is the STMLNCSSPject, which I created for practicing Git. Now imagine we are adding new feature. For example, drag and rob feature in this project. So instead of adding that feature in our master branch, we can create a new branch. Git branch is like a new line in our mets. So as we know when we commit our code, get give Master Pointer to our latest commit. Now as we decide we want to add new feature in our project, then first, we create a new branch, let's say, drag and drop feature or DND feature. Now, this branch has the same snapshot of our code. Here we can commit our new feature code and when we commit that code will not affect our master branch code. We can work on our code isolated. Now you might ask why we need to create branches. Can we even push our code to the master branch? No, we can't do that because if we write write code, then it's not the issue. But if we messed up with our code, then we don't want to store messed up code in our code history. If we create a branch and we messed up with our code, then we can simply remove this branch completely and it will not affect our master branch. That's the idea. Now you might ask, how does Git know on which branch or coat we are working on? For that, Git have another pointer called head. We have already seen that pointer. By default, our head pointer is with master or main pointer. If you work on another branch, then Git only move the head pointer to that branch commit. So that's how Git branches are working. For simplicity, just remember if you are going to work on something different, then you can work on that isolated by creating branches. In big companies, many teams working on different branches, so their code will not cause issue with the master branch, and we get a stable code in our history. 44. Creating a new Branch: Now for practicing the branches, we will use our previous project, which is course Task track. If you are starting with this section, then you can get this Task track project folder in the resources of this video. In this project, we will imaginary working on the Dragon drop feature. For that, we will create our first new branch. Creating the branch in Git is very simple. Just we have to write Git branch feature slash DND, which means dragon drop. Here, you can use any name. I'm using features las DND to clear that we are working on other feature, not fixing the bugs. It's totally up to you how you want to call it. I found this style more useful, so I'm using this. Now to see the branches, we can write, gate, branch, and take a look. Here we only have two branches feature slash DND and our default branch, which is master. Currently, we are on the master branch, and that's why we get star before Master branch. And we can also see here the current branch name. Now to work on DND branch, first, we have to switch to this DND branch. At the very beginning for switching branch, we have to use Git checkout command. But as this command is a little confusing, so get introduce a new specific command for switching branches, which is Git switch. Here we write our branch name, which is feature slash DND. See here our brand changed Lovely. Now, let's open this project in the VS code using code period. Now here, let's say we predict we added a drag and draw feature. To demonstrate, I open this JS folder and in that script dot JS file. And at the top, I add command by using Control Slash or Command Slash, adding ag and draw feature. At the bottom at console dot log, this is drag and drop feature. Save this file and see here we get the modifications. Now we can predict, we complete here our Dragonrop feature implementation. We can add these changes to the staging area using Git add period. After that, Git comt and message implement the dragon drop feature. See, here we get one file changed and two insertion. Nice. Now let's see the commits. Get log, one line. C, at the top, we have features slash DND commit and our headpointer is currently at the features DND branch. So I want to clear one thing is the changes we made in this branch will only visible in that branch. If we switch back to the master branch with kit switch master, see, here we get the old version of our code. Now, if we log our commits, here we don't get the feature slush D and D coat because that at is one step forward of our master Kate. If you want to see all branches, then we have to write here, gate, log, d dash, one line, d dash all. See, here we get the branch. In future, we successfully complete this feature implementation and we want to add that code with our master branch. We can merge that code in master branch. We will see that in the upcoming lessons. But after merging our branch to the master branch, we have to delete our branch. For deletion, we write Git branch D, here we write our branch name features D and D. Now, this will give us error or we can say warning, which is saying us that this branch is not fully merged because we didn't merge this branch with the master branch. Now if you surely wants to delete this branch, then we can write the same command with the capital D. Currently, I'm not removing this branch because in the upcoming lessons, I will show you how to work with branch and merge it. I hope you understand branches. In simple words, get branches help developers to work in isolation. 45. See the Changes between branches: Now, sometimes in our project, we can't actually remember what we change in our branch, especially when we take two, three days break. Then how can we see the list of Komats we perform after our master branch. So for that, we use kit, log, master, dot dot. Here, we write our branch name, which is feature slash DND. See, here we get only one amid which we did in the last lesson. If we did more than one commit, then we also get all those commits here if we want to see only commit message, then we can of course use dash one line. Now you might ask, what if I want to see the actual changes we made between our master and DND branch code. Do you remember which command we use foresee the difference between two commits? We use Diff command for that. We write Git, Dave, master, dot, dot, which are slash D and D. By this command, we see the difference between these two branches. See, here we get our one script dot JS file changed, which is in the JS folder and we can see these two lines are added. Here, I have a little shortcut trick for you. If we are working on one of these branch, then we can only write the other commit reference or branch name. In simple words, here we currently on the master branch. We can simply write here like this, Kate D and we directly write our branch name with which we want to compare. Feature slash D and D. See, here we get the difference. Now you might say these two outputs are different and that is true. The thing is here we are comparing master branch with our feature, slash DND branch, and that's why we get these two lines are inserted. Now in the shortcut rig, we are comparing feature, slash DND branch with our master branch, and that's why we get here two lines deletion. But that doesn't matter because we only want to see the difference. Sometimes we want to see only the files which are changed. So for that, we can write Get did name only, or we can use n status, and we write our features DND branch. See, here we only change one file which is script dot JS file. So if we merge this DND branch with our master branch, then our only one file will get modified. We use your name dash only option, then we get only the file names. But as we use name dash status, then we get the file names with modifications, insertion or deletion status. Now in the next lesson, we will see sassing git. 46. Master Stashing: Now before we start learning stashing, let me give you one condition. Imagine you are working on your important project and you are at the half of your code. Now suddenly your manager comes to you and tell you to fix the bug in dragon drop feature right now. Now in this situation, what will you do? One option is you can commit the changes which you made then work on dragon drop feature. But as I told you, you are at half of your code. You can't commit this code. It looks unprofessional. Now, what is the solution in this situation? At the time, we can store our current changes in the corner of gate and when we are done with our other task, then we can switch back to that changes. This way, our half code will not stay in commas and we also don't lose our half code. This process by which we store our half code in the corner is called atsing Sas means to hide it somewhere. To show the half code, I add in the script dot jslecs dot log. This is half code. I don't want to lose. Save the changes, and if we check our current status, here, we get one modification, and if we try to switch to features DND branch, then we get the error which says your local changes to the following files would be overwritten by checkout. Please commit your changes or stage them before you switch branches. Basically, it is saying, if we don't commit or stage the changes and try to switch to another branch, then we will lose those changes. So for stashing the code, we write Git push A, and here we write our stress message for the summary. Let's say, working on modifications of website design. See, we get saved working directory and index on Master. Now we want to see all stass we made in our project. Then we write Git stats list. See, here we get the Ss, mark as at the red in curly bracket zero on Master branch and our SS message. Now here is one thing. This git stash push command will not add untracked file in the stairs. For example, here in the JS folder, I create a new file called tamp dot js. And in that file, I add command temporary file. Save this. And if we write Git status, here we get the tempt JS file as untracked file. So if we run here Git push, then Git will not add this file in our stash by default. So for that, we have to write here, or we can write A, then for stash message. Here we can also combine them, and then we write our stash message, which is adding a temp file. Now, if we again run git stash list, then here we get to stash. See here our first dash, move to the stats aerate one, and our last dash added at stats aerate zero. Here we successfully sash our current changes. Now we can switch to the feature DND branch using Git switch, features DND branch. See, here we get the current branch name, and in our code editor, our script file is also changed to the features DND version. Remember, we edit this console line. Now imagine we complete our work on this branch, so we can again switch to the master branch. Now we want to get those changes which we added in the stash. Now before adding those changes, we want to see what are those changes. So to see the changes, we write Git show, and here we write the name of our stash which is iterate in Ci brackets, zero. Now here, if you don't want to write this weird name, then we can only write this number zero. See here we don't get anything because in that stats, we added only untrackfle temp dot js. By default, don't show track file in this command. So to also see untrackFle, we have to add here U. See, now we get Temp dot js file and one insertion. If you want to apply those changes in our local working directory, then we can write Git apply zero. See, now we get track file and also we can verify it in our code editor. Good. Now as we apply those changes in our working directory, we don't need this zero. So we can remove the stash and we don't want to gather too much stash in our project. It is very good practice to remove stash which we don't need anymore. We can write Gates drop zero. Now, if we see the stache list, then we don't get the stash. Now let's simply apply this stash our working directory. We write Git, apply, and what we write here, write. We write here again, zero because we remove the first zero and get mark our one to zero. See, we get two changes in our project, one in script file and one track file. Let's remove this one stress also. So we can write it drop again, zero. Or we can also use it clear. This command will remove all stasis from our project. See, all stasis are gone now. 47. Understanding Merge in Git: Now here, imagine we are done with our drag and row feature, so we want to merge this code with our master branch. But before doing anything, first we have to check the current branch. See, we are on the master branch. So first, we have to switch to the feature slash DND branch. But here we have some changes in our working directory, and that's why it won us for switching. But here we don't want those changes, so we can forcefully switch to our feature slash DND branch. For that, we have to write gate, switch, four, feature slash DND branch. Double check your code before running this command in your projects because you will lose your changes permanently. Now, in our scrap dot js file here in the Console, I write done with drag and drop feature and also remove this command from the top let's remove this console. This file and also remove this stamp dogs file. We don't want that. Now back to terminal. Here, we first stage our changes. And then we can simply Git Cate M, complete, drag and drop feature. Good. Now we want to merge our features DND branch with our master branch. So there are two types of merge in Git. First one is fast for merging and second one is the three way merging. Let's see each type of merging with simple example. First, we will see the fast for our merging. So here we have multiple amides, and after that, we create a new branch called feature D&D. Now in this branch, we did multiple comets. Now at this stage of the aid, we're done with our feature, and we decide to merge our feature branch with master branch. So at that time, we can directly merge these both branches without worrying about anything. This merging we called as fast war on merging. Now let's see the three way merging. Previously, after creating the branch, we didn't commit anything in our master branch. But in real world, this happened very rarely because as we know, there are many developers working on one single application. There is one possibility in which other developers will commit in the master branch. At that time, our branches get diverse. So we have some changes in master branch that we don't have in our features S D and D branch. Now if we run merge here, Git don't move our master to the feature slash DND commit because this will remove changes from the master branch. So when we run here merge command, Git creates a new commit which combines the changes from these two branches. Now you might ask why we call this merge as three way merge Because it depends on the three commits. First one is the common joint point of two branches. Second one is the last met in the master branch, which is called as tip of the master branch, and third one is the tip of the feature slash DND branch. Git look these three comets and merge our code according to that this new comet which created by gait is called as merge Camt. To recap, there are two types of merging. First one is page for or merge if our branches are not diverge or we can say we didn't add new comet in our master branch after we create a new branch. Second is three way merging if our branches are diverge or we can say we did a new commit in the master branch after we create the branch. Now in the next lessons, we'll see these two merge. Don't worry, it is really simple. 48. Applying Fast forward Merging: Now, let's see the fast for our merging. To quickly recap in fast for merging, we have linear commit path and get directly moves the master pointer to our features DNDAsKt. Let's see how we can do that. First of all, we will log all our codes, and as we know, if you want to see the branches, then we have to use it log, dash one line, dash dash all. And when we are working with branches, we can write here dash graph option. Highly recommend to use this graph option because it will show us we have diverse comets or not. Also, you don't need to write this long command every time. You can use as for that. Now currently, we don't have diverse comets and that's why we can't see diverse graph, but it is look like this. Now we can see currently we are at the feature DND branch because our head pointer is here. Now to merge this feature DND branch in our master branch, we have to first switch to the master branch. Good. Now we can see our head pointer is moved to the master branch. Now to merge these branches, we write git merge, and then we write our branch name, which we want to merge in master branch. See, here we get fast for our merging. Now we can again see all comets using our previous command. See here we don't get new comet just move over Master pointer to the feature SS DND branch because we have linear comets or we can say we don't have diverse amides. What if sometimes we don't want to apply fast forward merge. It's totally fine. In git, we can also apply non fast forward merge, and we will see that in the next lesson. 49. Non Fast forward Merging: Now, let me show you how can we avoid fast forward merging. So to demonstrate, we have to create a new branch, and then we have to switch to that branch. So these are two different step. Let me show you shortcut to do these two steps in single step. So we can write gate switch C for create here we write our branch name. Let's say features Feedback. See, we directly switch to the feedback branch. Now back to VS code, and here I open index dot stMLFle. If you wonder how I'm opening the file, just press Control plus P or Command plus P and write file name here. Now at the bottom, after our main tag, I add one comment for feedback form. Imagine we add here feedback form, save the changes, and back to our Git Bash. Here, first we stage all the changes and then commit the changes as commit message done with the feedback feature. Good. Now, let's check our comment history. See, here we get our last commit. Now let's merge this feedback branch with our master branch by non fast forward merging. What we will do before merging, we switch back to the master branch. Now here we write Gate, merge, Ff for no fast forward and simply write here our branch name, which is feature slash feedback. By this command, we are telling Git, if fast forward is possible in this merge, still don't do it and make a new command, which combined two branches. The easy difference between fast forward merging and non fast forward merging is in fast forward merging, git don't create a new commit, but in non fast forward merging, Git creates a new command. Now, the moment we hit Enter here, Git ask for merge commit message. By default, we get here this commit message generated by git. If we want to change it, then we can change it here. Save the file and close the file. Now in our terminal, we can see merge done. And if we see history with graph option, see, here we get the graph of our commits. We can see our Master Pointer, but our feature feedback branch is still there, and Git create a merge commid which combine features feedback changes with master branch. And we get this graph because we add graph option in our log command. Now you might ask what is the best thing for merge? Fast merging or we should use non fast for or merge. Let's see pros and cons for these both merging. First of all, when we use fast for merging, we can see our history very clearly because there is no diverge in comets. But if we use non fast for merging, then our history might look a little confusing. Right now, we can see that because we have only one diverge. But in real world, big projects don't have only one branch. Are multiple branches and many diverse branches. That's why non fast for merging looks little confusing that also means fast for merging has more visual clarity and on the other hand, we have less visual clarity about our comets. Now, another thing is, if we use fast forward merge, then we might skip some contexts like when specific changes are integrate. But if we use non fast for merge, then we don't lose any contexts. With each merge comets, we have details about when and where we make changes. Now after that, in fast per merging, we can't isolate our two branches code. But in non fast for our merging, we can isolate our two branches code because we have separate merge gummets. These are the pros and cons of these both merges. In my opinion, these both options has pros and cons. You are working as individual, then you can select whatever merge type. It's totally up to you. But many times your team will tell you to use fast forward merge or not. Now, when we are in flow of our work, we might forgot to use no fast forward option, and your company tell you to use only non fast forward option. So the solution of this situation is we can set non fast forward option for our current repository, or we can also set it for all it repository in our system. For that, we can write it config, FF, no. This command will disable fast forward in our current repository. Also, if we want to disable fast forward for all repository, then we can simply addhee dads Global. 50. Understanding 3 way Merging: Now let's see three way merging. As we know if we create a new branch, make commit on that branch, and then we also commit on our master branch, then we can call these two branches or diverge from each other. Now in this situation, look at the both tip of these branches and also look to the common comet by where these two branches get diverge. It figures out the best way to combine these both branches and apply those changes in the new comet. To demonstrate this, we again, create a new branch. Using gate switch C for Create, and then we give our name feature slash user Register. Now back to the VS code. Here in the project folder, we create a new folder called user register. And inside this folder, we create a new file called register form dot SGML. And inside this, I quickly add HTML snippet and change the title to the register as new user. Save this file and back to our terminal. Here, first we stage all changes and then also commit them on our user register branch. Good. Let's see our history by using Git log, dash one line, dash all, Des dash graph. See, here we get our new branch. Now, let's switch back to the master branch. In the script dot js file, we add here console dot log line, and here we console learning the three way merging. Save the file, and in the Git Bash, first, we stage our changes, and then we simply commit changes. Git, update script dot js file for three way merging. Good. Now let's again see the history. Here we can see the diverge in our branches. If we are working on this branch, then we can directly go here on the master branch. This is called a diverge branch. Now let's merge these two branches. Here is one good news for you. We don't have separate command for three way merging. It is the same command which we use for the fast forward merging. If we have diverge branches, which means we had comes in the master branch after we create a new branch, then get automatically apply three way merging. What is the command for merging? Right, git merge, and here we add feature slash user and press Tab. It will auto complete the command. Here, ask for the merge commit message. I leave it as it is, close this file and see here our branches get merged. And if we see our history graph, then we can see here we have our branch comet, and here we have amid, which we did on our master branch, and Gate merge these both comets in this separate merge commit. That's how three way merging works. You might ask three way merging and non fast for merging are same, and I had the same question when I was learning merge in gait. The answer is no. They are not same. They might look similar, but they are not same as each other. The difference is if in merging, we have linear comets and we still want to combine branches in the new merge comets. This is called as non fast forward merging. But in three way merging, we have always diverge comets, get automatically combined branches in the new merge comet. That's the difference between non fast for merge and three way merging. Now in the next lesson, we will see how can we remove merge branch from our repository? 51. Clear branch after you merge: I now when we are working with branches in the git, if we complete working on one branch and merge them into the master, then we don't need that branch. It will create confusion for us and for our team members also. Let's check which are the branches we have created by using git branch. See, here we have four branches, and now I want to know which branches we merge in our current branch, which is master. We write git branch, dash merge. See, here we get the list of commits which are fully merged in our current branch master. Here we get all branches because we merge all these branches in our master branch. Now we can remove the branches using Git branch, D, and we write our branch name, let's say feature D&D. Now, if we see the history of our ames, then feature DND removed from the history. Here is the before and after history. See, just remove the branch from here. The amid will stay there as it is. Currently, I'm not removing these other branches because I need them in the future. Now let me give you one bonus. Instead of watching the branches which are merged, it's easy to directly see the branches which are not merged, so we can merge them in the future. We can keep in our mind to not drop that branch by mistake. For that, we write git branch, no, d merged. See here we don't get any branch because we merge all branches in our current branch master. Now in the next lesson, we will see how to resolve conflict in git. 52. How to resolve conflict in Git: Now before starting this lesson, I want to ask you simple question. Imagine we have two branches. One is master, and second is the feature slash login. Now imagine we change the index dot SM file in our master branch and commit the changes. And also in the features login branch, we change something in the index dot STMLFle. In short, in these both branches, index dot SML file is different. That time, if we merge these two branches, then Git will confused which changes it should take and which changes it should avoid. And that is called as conflicts in Git. So when we change same file in different branches, and Git can automatically merge those two branches, that is called as conflict. Now you might ask what are the possible solutions in which conflicts occur? So first one is change. We change the same line of our file in the both branches. After that, in one branch, we delete a file, and in the other branch, we change that same file. There also conflict occur. Also, we rename the file name in one branch and the same file in the other branch. Also, we add file one dot TXT in the first branch, and we also add file one dot TXT in the second branch, but content of the file is different than also conflict occur. These are the common situations when conflict can occur. Now, you might ask what it will do in this situation? And what is the solution for resolving the conflict? Simply git will ask us and give us options which changes we want to do. It will not interfere in the conflict. It will simply ask us what we want to do in this situation? Let me show you that practically. For demonstrate the conflict, we have to first create a conflict. Let's write Gate switch C, feature login, and what this command does write. It will create feature login branch and also switches to that branch. Now let me change in the scraptGs file. The second line, I write here, console dot log, Console for feature, slash login branch. Save this file, and let me stage the changes and also commit these changes with commit message, modify script dot js file for features login. Done. Now let's switch to the master branch and also in the VS code, we also change the second line and write here, Console for master branch. Save this file. And let's taste the changes. And also, we commit with message, Modify script dot js file for master. Now, let's try to merge these two branches. So we run Gate merge, feature slash login. See, here we get conflict and gate saying merge conflict in script dot JS file. And also, it says, automatic merge fails and fix conflict, and then committer result. So here we have to manually do the changes and we can also see we are in the middle of merging. Let me show you the current status by git status. See, here we have unmerged path. Let me show you something cool. Open VS code and see, here we have changed line highlighted, which is causing conflict. Don't get confused by this screen. It is really simple. See, first we get the header pointer, which is indicating the current branch which is master, and below that, we have the change, we commit in the master branch. After that, we have line for separation, and then we have the change we done in feature ss login branch. See? Here we have a couple of options which VS code gives us. First one is accept the current changes. If we select, then it accept the current changes, so it will apply changes from the current branch. Let's undo this using Control plus set or Command plus set. Now, if we select accept the incoming changes, then it will apply changes from the second branch, and we can apply both changes, and last option is to compare both changes. It will compare our files side by side. So let's close this comparative. Here we have options by VS code. We can also manually change the file. So let's remove this feature, slash login pointer, and also remove this line separation and also remove this head pointer. If we want to move these lines up and down, then we can also do that. But always remember here we don't add a new code because the main goal of the merge is to merge two branches code, not to add a new code, but sometimes we must have to add new changes. If it is not avoidable, then you can do that also. Now after we're done with our changes, we serve the file and back to terminal. Here, we have to first stage the changes by git add period. Now let's check our current status. See, we don't have unmerged path. We can write Git commit and we get the commit message here. I leave it as it is, close the file and see, we merge our two branches, and also merging state is gone. 53. Abort conflict in Merge: Now, sometimes we run the merge command and it give us conflict, but at that point, we don't want to resolve that conflict because conflict happen by mistake. So instead of going forward in the merging state, we go about this merge command. For that, I'm not going to create a new branch and create conflict. I will show you my previous screen recording before we resolve our conflict. Here we run Git merge command. See, we have conflict. We don't want to go further, we can write, gate, merges about, and see we are step back from the merging state. 54. Reset the Merge Commit: A now sometimes when we merge two branches and our code stop parking or crashed, it may happen because we do some mistake in merging branches. So there are two solutions for this situation. First one, we can reset our merge commit to the previous amid before merge. And the second option is we can undo our merge code and commit it in the new at. Don't confuse by this, let me explain you each scenario. So first, we see the reset merge comet. So here in our Caid, our head and master pointer is on our merge met. This is our branch pointer. Now in this merge commit, we get the issue. So we can reset our comet by moving this both pointer to the previous at before we do merging. Basically, we are resetting the merge coat to the previous coat. Now you might ask what will happen with this merge commit? So as we move our master and head pointer to the previous at, this amid become pointless. After some time, it will automatically remove this amid from our repository. Now as we can see indirectly we are changing or rewriting the commit history, and that is okay only if we have repository locally. But if we have many team members working on this project, then we don't consider this option. In this situation, when we have team members working on same project, then we have to revert our code and commit it in the new command. So again, we have our commit history. When we revert our merge, then Git was the two tip of the branches. Now, instead of moving this both pointer with the previous comet, Git take the changes from the previous amet, undo it, and then do another comet which is the revert commit. We can see this previous commit code is the same as this revert commit code. This method is more convenient because here we don't rewrite our Git history. Let me show you this both method one by one. First, we see the reset option. So for that, we write git reset, dash dash hard. We write here hard. I will explain this in just a minute. And here we write our commit reference, which we can call as head till one. Now before running this command, make sure you write the commit as of this merge ammt somewhere in your nodes. Now, basically, this command will tell Git to move the master and head pointer to the previous commit. Here you might ask, what is this hard option do? So when we run reset command, we have three options, soft, mixed and hard. Let me explain you these in details. So here we have our working directory code, staging area code, and we have our Commit code. Now when we run reset command with the soft option, it will only reset our commit code to the specific commit, but it will not touch our staging area code working directory code. So our changes in the working directory and staging area will stay the same as we currently have. Now, if we use DSDs mixed option, which is the default option, it will reset the commit code and also modify the staging area code to that specific commit. And now can you guess what this hard option does? Right, it will reset the commit code, staging area code, and also the working directory code to the specific command. So that's why we use hard option with the reset command. So let's run this command. See, here we get head is now at this commit and we can also see the commit message. Let's check our history again. See here our head and master is moved to the previous commit on the master branch, and we don't see our merge commit in this list, but we can still move to that commit because Get remove that commit immediately. We write git reset dash had, and here we write that merge commit, which is E seven, E seven, d eight. See now our head is moved to the merge commit. We can see in our history, we get the same merge mit. Now in the next lesson, we will see the better way to undo merge, which is by revert. 55. Revert the Merge Commit: Now, let me show you second option for undoing the merge, which is by reverting merge changes. So for that, we write git revert, and here we write our commit has, which we want to revert. In our case, it is this head commit. So we write here, head and hit Enter. See, here we get error. Commit is merge, but no option was given. Revert fail. So what is the option Kit is talking about? So here is our merge commit. When we say revert to merge commit, Git has two option. First, G will revert commit to the last commit of the master branch, and we call this commit as first parent because we are on the master branch. Now second option is it will revert to the last comet of the feature branch, which is called as second parent. So we write here git revert M one, which is the first parent of our current branch, which is master, and which commit we want to revert, we want to revert head commit. We want to revert changes as second parent command, then we can write here M two, but that is rare. Let's change it to the one and hit Enter. Now get ask for the command message. I don't want to change it, so I simply close the file. Now, let's see the history. See at the top, we have new Commit, which is the revert commit of this merge commit. That's how we can revert our merge without rewriting the commit history. I always prefer to choose this revert option instead of reset, but ultimately choice is yours. If your project is local, then you can use whatever you want. But when working with team, reverting is better option. 56. Squash Merging in Commit History: Now, before learning squash merging, which is another merge technique, let me give you one situation. So here is our commit history, and we have one branch called Fix Bergh Login. In this branch, we fix bug in our login feature. So in this branch, we have a couple of commits F one, F two, and F three. We are done with the fixing bug in the login form. We can merge these two branches. Now here, as we can see, this F one, F two and F three is a part of our commit history. But for fixing the bug, imagine we did some bad commits, like change this little bit and commit it. We are at the half of our fixing the bug, and for just checkpoints, we done these comets. In this case, we don't want to add this F one, F two and F three in our commit history. So the solution is before we merge our branches, we create a squash kami, which is the combination of this F one, F two, and F three all in single comet. And then we can simply move our master pointer to this comet. But remember, this is not the merged at because this comet don't have two parent met and we can also see it is not connected to the F three comet. As here we have all changes of this branch, we can drop this branch from our met history, and now we have linear history and we don't have bad branch coat. This is the benefit of using squash merge. Now you might ask, should we always use squash merge technique? The answer is no. We will only use squash merge when our branch comets are bad or we don't want to keep the comets in the history. For example, I like to use squash merging when I work for fixing small bugs or very small feature, which I can complete in one to 2 hours. The situations, I don't need those checkpoints. But if the feature or bug is big, then I don't use squash merge and keep the checkpoints in history. Now let's see squash merge in our project. Here, first of all, let's quickly create a new branch using Git switch, C Fix Bugs Login. We go to the VS code for change, I remove these three console lines and adhere newconsole dot log. Fix log in bug Checkpoint one. Imagine here your office hours gets over and you want to fix the bug tomorrow. So that's why CheckPoint one. Save this file now back to our terminal, and instead of stage and Comet in two steps, we can use here shortcut which is Git AM and write commit message, pigs bug in login feature, checkpoint one. Good. Now to demonstrate more clearly, we will do one more commit in this branch. In our case, we come next day in the office and fix the bug completely. So vis Cd, and here we remove the checkpoint one because we fix the bug completely. Now again, back to terminal, and here we write gate com AMFigbug in login feature complete. Good. Now let's see the history. See here at the top, we have two branch commits. But as you can see it looks ugly. What is this checkpoint? Here, we apply squash merge. It is really simple. Basically, commands are very simple, just making that situation taking more time here. But it is important to show you the real example. Now here you might ask, can we do here push for a merge Because we don't have diverge branches? Yes, we can do here fast for our merge, but in this case, we don't want to save these both comets in the history. We just want to save the changes, and that's why here we do squash merge, which will combine changes of these two branch comet. First of all, we have to switch to our master branch. Now, previously, we write for merge, Git Merge, Fixburg Login. But for squash merge, we just add here options squash. So here we can see we done squash Kammit. And here is the list of files which changed. In our case, we have just one file because we only change the script dot JS file, but it didn't directly add that commit in our history. These changes are just in staging area. Let me show you. We run Gate status, C, here we get script dot js file, which is modified. Now we can commit these changes, gate commit. Here we write combine commit message, which sows all changes happen in this branch. Let's say fixed login page bug by fixing data type and endpoint in API request. Good. Now, let's see the history. See, at the top, we have another comet, but it is not linked with the Fix buerg slash login branch. So when we remove this fix buurgs log in branch, then we get clear and linear commit history. Now, here you might ask, what if we don't remove this branch? Ideally, we should delete the branch after doing squash merge because this branch is not declared as the merged branch. Let me show you what I mean. If we write Ket branch, dash merged. Here, we get FixBurG login branch as unmerged branch. But as we know, we already added this branch code in our history using squash merge. This will create confusion in our history. So it's better to drop this branch when we do squash merge. Do you remember which command we will use for dropping the branch? Don't worry. If you don't remember, you can use the cheat set also. We write Git branch, D, and here we write the branch name which is Fixburg login. Here we get error, which is saying branches are not fully merged. So here we have to forcefully drop this branch. You bring the previous command and simply we remove this D and add here D. C, our branch deleted successfully. Now, if we check our commit history, we get cleaned in your history. We use squash merge when we don't want to save bad commits of our branches. 57. How to Rebase the Branch: So what is rebasing in git? Rebasing is a technique which is used to change the base commit of the branch to another commit. Let me explain you with the example. Here is our commit history and we are working on the branch called features OT. Now here, while we are working on the OT branch, let's say someone had commit to the master branch. Now we want to merge these master branch changes into our feature branch without creating the unnecessary merges. Here, what is the solution? One solution is we merge these both branches and then continue to work on them. But then we have to create also another feature less oth branch. We can do that. Another solution is we can use rebasing, which basically means we can change the base of our branch. Currently, this is the base of our oth branch. If we change our base to this latest master commit, then we get to changes in our oth branch without merging the branches. That's what rebase is. We are simply changing the base commit of our branch. Now here is one thing you have to keep in mind this rebasing technique, rewrite our met history. When we change our base to another amet, then Git don't change the original F one Kamete. It's simply take these two coats and create a same amet as them and then link them with the latest master coat then simply move this branch point here. Now, as we can see, these commands are not connected with the F to commit, will drop this F one and F to commit. That's why rebasing rewrite the command history, and that's why we will only apply rebasing when we are working locally without any team members. Otherwise, our history become mass. Now let me show you how we can perform rebasing. First, we have to create a new branch using Git switch, the C feature OT and back to VS code. Here we simply create a new file in Jsfolder called auth dot js. And here we simply console dot log working on authentication. Save this file. Now less these changes. And then commit it with message at orth dot Jspile for rebase. I know this is not proper message, but for demo, it is okay. So now we have branch with one Kat. Let's check our history. Here, we have to do one kamite in master for create diverge kamits. So first of all, we will switch back to the master branch. Open VS code, and I will do changes in the script dot js file. So here I simply remove this console message, and right here some changes required for OT branch and save this. Now back to terminal and let's taste the changes, good, and we also commit it. Git commit M, changes which are required for OT. The now let's check our history. See, now our history is diverge. If we don't diverge our branches, then gait, by default apply fast forward merge. Now we have our diverge branches. Then we have two options. We can apply three way merging or we can rebase. Currently, our oth branch is pointed to this at. Now in rebasing, we will make our oth branch pointed to this summit, which is the latest amid in the master. For rebasing, first step is we have to move to the branch which we want to rebase. Here, we want to rebase our features OT branch, and after that, we will apply rebase. We will first switch to the feature OT branch. Now, what is the command for rebase? It is really simple. Write git rebase, and master. Basically, we are telling Git. We want to rebase our current branch to the Master pointer, which is currently at the latest command in the master branch. See, we successfully revise our branch. In the real world, many times during the rebasing, we get conflicts. I will show you how we can deal with conflicts in the next lesson. Currently, we just focus on the simple rebase. Let's see what we will get in the history. See, here we get linear history. Now, if we want to merge these, then we first switch to the master, then we simply run get merge, feature OT and done. See, here we get fast for our merge because we have linear history. To explain you this more clearly, here is the before and after history. We can see we don't get the same branch coat. As I told you, did create a new comet, which is the same as that old branch kmete. If we have three meds in the oth branch, then we can here three new coats. Now in the next lesson, we will see what we will do if we get conflict during rebase. 58. Resolving Conflicts while Rebase: Now let's see how we can deal with conflicts during rebasing. There is nothing special about that. We will do the same process as we resolve conflicts before. But there are two, three useful commands which we need during this. So first of all, have to again, create a new branch. Let's say I'm literally running out of the name here. Let's say FixbugOT. Now let's do some changes in our index dot STML file. Here, I change the title of our website. At then we just write Fix Auth bug. Say the changes and back to our terminal. Here is a quick tip. If you don't like to switch between two windows, then you can also open terminal in the VS code. Just press Control plus Batak or Command plus Batak. I like to use itbash so I switch to that. First, let's stage our changes and also commit to changes, Gate commit Fixburg in authentication. Good. Now we have to commit changes in the master branch and in the same line to create conflict. So let's switch back to the master branch and move to the VS code. And in index dot STL file, we also change the title, adhere to more exclamation mark. Save this file. Let's taste the change and also commit the changes with message. Change the title of website. Let's check our history. See, here we get diverge branches. Now, we simply rebase this branch to the latest master pointer. What is the first step of rebase? We switch to the branch which we want to rebase. We switch to the FxburgOth branch. Then what we will do? Simply, we write kit rebase master. See here we get the conflict in index HTML file. Let's open VS code, and here we can see conflict. Now here we can select from these three options. I select here first option, except current changes. Save this file and back to terminal. Here we can see we are in the rebase process. Now here we have only one conflict. If we have multiple conflicts, then we have to solve them all. After that, we simply write git rebase, dash, continue to continue the rebase process for the next branch comet. If the next commit also has conflicts, then we again solve them and again run this git rebase, dash continue command. We continue until our all conflicts will resolve. So if for some amide, we want to skip the conflicts, then we can use here another option, dash dash kip. This will skip the current conflict of our amid. For example, we get conflict and we don't want to resolve that conflict, then we use here Skip. Also, we have another option, which is dash About for about the rebase process without resolving the conflicts. This is very useful while we get so many conflicts and we don't want to resolve them here. So in this situation, we can about this rebase process. See, we are out of our rebase process. Now we are not doing here rebase because it is the same process which we see in the previous lesson. And another reason is we have diverge branch which we need in the next lesson. So that's why I aboard this rebase process. If you want to do rebase, then you can do that. But in the next lesson, you have to create diverge branches. So as you can see, rebase is literally rewriting the history. So that's why use rebasing with local projects. 59. Cherry Pick Technique: Now here is our Cate history. Suppose we have as in the WigbergOth branch, A one and A. Now here we want to copy this entire Evan Camt and add it into our master branch or some other branch. You might say we can merge these both branches, but here is the problem. Our Fixburgoth branch is not ready to merge. We have some work to do in the Wigberg slash Oth branch. Now at that time, we will use one technique called a cherry peg. When we want to copy one entire gamete from one branch to another branch, then we will use cherry picking technique. Here in our project, we can see we have our master branch and we have FigburgOth branch with one Camt. To demonstrate more clearly, we will create one more gamete in the auth branch. Currently we are on the Wix per South branch. In the VS code in scrip dot js file, we simply add another console line, write changes for second commit for FixbuGOT. These changes are not matter because we are not working on the real project. Here, our primary goal is to learn git, save the changes, and back to our terminal. Let's stage and commit together. Gate AM fix the Auth bug in scrape dot JS file. Now you might wonder why I use this command together and why I use it sometimes separately. The single command will run only when we have updates. If we add new file, then first, we have to stage that file, and then we have to commit it. Good. Now let's see the history again. See in the one branch, we have two gametes and here we have one gamete in the master branch. Now let's cherry pick this first met. So this commit has which we want to copy. For me, it is e67 90d4, where we want to add this commit, we need this commit copy in our master branch. First of all, we switch to the master branch. Now we write it cherry Pik here we write our commit, which we want to copy. See, here we get conflict, and that's why I told you to not resolve the conflict in the previous lesson, and we can also see we are in the cherry picking process. When we have conflict, we simply go to the VS code and resolve the conflict. Here we accept incoming changes. Save this file and back to terminal. Here we check our current status. See here we get merged path. So we have to stage our changes, Gate add period. And now let's again check the status. See unmerged path is gone. So now we can commit, Gate, commit, and hit Enter. Open via code, and here we write commit message. At the end, I just write copy so we can quickly identify. Let's see our amet history. See, here we get the new copy kamet and still our branch is same as before. So we copy the changes of this amet without merging the Fibergoth branch in our master branch. Now, let me tell you why it give this technique name as cherry picking. So cherry picking name reflects the selective nature of this process. So if you see cherry tree on that tree, we have many cherries. But for eating the sweet cherry, we have to select specific cherry from the tree, and then we can enjoy the cherry. My mouth is getting full of water. Now as we are picking specific cherry from the cherry tree in git, we have mitre and we are picking specific commit and taking the advantage of that commit. Same as we pick cherry. That's why Git called this technique as cherry picking technique. I hope you like this. See you in the next lesson. 60. Add specific file to another branch: Now in the cherry picking technique, remember, we copy entire amet. But what if we just want to copy one specific file from the Kami? So here how we can do that. So currently we are on the master branch, and if we look at our script dot js file, then here, we get only two console lines. Now if we switch to the FxburgOth branch, and see, in our script dot js file, we get two console lines. Now we want to copy this script dot js file from the FxburgOthBranch, and add it in our master branch. We again switch back to the master branch because we want to add the file in the master branch. Here we write Git, restore the source equals to, and here we write our brand name from which we want to copy file, which is Vicksburg oth. Now after that, we write our file path which we want to copy. We write Js script dot js. Make sure you write the file path, not only script dot js. Otherwise, you will get error. Here we can also separate our file name from the command using double dash. We already seen that. Remember, here we are telling get copy script dot js file, latest version from the WigbergOth branch, and paste it in our current master branch. Now, if we check our script dot js file, here we get two console lines which are the same from FixburgOth. Now we can stage the chins and if you want to commit, then we can also commit our code. That's how we can copy one specific file from one branch to another branch. 61. Branch & Merge in VS Code: Now let's see branch and merge feature in our VS code. First thing I want to clear is VS code has not all features, which we do using git commands. So let's see what we have in VSCode. Open up source control. Here, we get our stage and stage files. We already seen that. Now here at the bottom, after comes, we have branches section. Here, we can see all our branches. We have master Fix bougOT and we have feature branch folder. Now you might ask, we didn't create this feature folder. Then who created this? Let me tell you we create this because we use forward slash in the branch name, and for all features branches, we use feature slash the branch name. That's why we get here feature folder. If we have more than one branch with Fix Berg, then we also get here Fix Berg folder. Now here we can see currently we are on the master branch because we have here Tick Mark. Also, we can switch branch from here. Also, we can create a new branch from here. Also we have view branch as list, and few more options. Now, if we click on any branch, here we get to compare option. Select the, and here we write our brand name which we want to compare. Let's say PisburgOT. See now this option converted into dropdown. We can see here files which are changed or effected. Currently, we don't have any file here, but if we have files, then by clicking on them, we can see the changes. Now let me show you how we can perform merge. Right click on Fix Burg Oth branch and select merge into current branch. Here, we get many merge options. First, we have merge, which is the simple merge command like git merge and branch name. After that, we have fast forward merge. Here we can see we have fast forward only. By that, we are telling gait, only use fast forward merge if possible. Otherwise, leave it as it is without merge. Next, we have squash merge, then we have no fast forward merge, and at last we have without fast forward and without commit, or we can also cancel or about demerge. Let's simply select default merge, and we close this commit message file and see merge done. Now, if we see our amides, then we get here merge commit. Now, if we write leak on previous Camt then we get here revert option. Here we select simple revert and see here we get the revert turn. Now we can also reset our Camt Here we get couple of options, soft, hard or mix. For now, let's cancel this. As we can see this source control is very confusing for branches. I hardly use this source control for branches. For branches, we have installed Git Lens extension, which is the great tool. Here, click on Git Lens icon. Here at first, we get Commit graph icon. Click on that and see, here we have Commit graph. Now to see this more clearly, I close this Git lens extension, and also I close these all files from the top and click on this open in Editor area option. Let's close the terminal window. See this graph looks more clear. See, at the beginning of this project, we have linear history. Then we create our branch features feedback, and then we merge them into master branch. After that, we create another branch and again, merge them in master. Now at the top, we can see here we have branch. Now, if we click on any branch, we have a couple of options. First, we have switched to another branch, reset changes, rename the branch, create branch, create tag, et cetera. Now let's create a new branch here. Enter branch name. Let's say Vicksburg slash registration. Hit Enter, and here we have three options. Create a branch, create and switch, and cancel. So we select Create and switch. Now let's open one file, press Control plus P or Command plus P, and openscrip dot JS file. Here, we do some changes. Save this file, and let's commit these changes. So go to Source Control. And here we write our commit message. Let's say, work on registration for Fix Berg and done. Now, let's back to the Commit graph. See here we can see our current active branch is FixburglaRgistration, and we also got our Commit. Now, if we right click on the master branch, then we get here more options, switch to the branch, merge with current branch, rebase, rename, and much more. See, here we get the same options which we have in the source control. The next lesson, we will see how we can see branches and merge in Github desktraPablication. 62. Branch & Merge in Github Desktop: As we know, for graphical user interfaces, we have two applications. First one is Github desktop and second one is it Kraken. If you are sure you want to use it Kraken, then you can skip this lesson and directly move to the Git Kraken lesson. Here is the interface of Github desktop application. Now for branches, we have here list of branches. See, here we can see our current branch. Now for switching the branches, we have to just click on that branch. See, our branches changed. Here at the top, we have option for creating new branch, which is very simple. Now here at the bottom, we have option for chooser branch to merge into master branch. Let's select that and here, we have to select the branch which we want to merge. Let's say FixburgRgistration, which we created in our previous lesson. Click on FixburgRgistration. Let's select Rate Merge Camt. If we have conflict, then we can resolve it from the VS code and then continue the merge. Here we get the success merge message, and if we check our commit history, then you can see merge commit. Now, if we want to access more branch options, then we have this branch menu. Here, we can create new branch, rename, delete, compare, merge into current branch, squash merge, rebase, et cetera. Now let me show you comparison. So like compared to branch, and here we have options for comparing. But as you can see here, we can't properly see the commit history with branches. That's why many developers don't like Gitub desktop. If you like Gitub desktop, then you can use VS code Commit history for watching the commits and branch and then use Merge Tool in Github desktop application. This is better option. Ultimately, choice is yours. 63. Branch & Merge in GitKraken: Now, let's open Git Kraken application. The history penal still my heart. See how beautiful it looks. We can clearly see the branches and commit history way better than using VS code or Github desktop application. See, here we have clear graph for branches, which we can easily understand. At the top, we can see list of branches. And if we select any branch, then we can switch to that branch. Very simple. Let me show you how we can create a new branch. Right click on the branch and here we have a bunch of options. Let's select Create a new branch. Here, we give branch name. Let's say feature slash Log Out. Here we can see we get Auto switch to that branch. Now let's do some amas in this branch. Back to VS code openscrip dot sple and simple at last, we at console dot log, implement Logout feature. The changes and let's commit these changes. Give the commit message. Let's say implement Logout feature and commit it. Quick tip here, if we want to see the current active branch, then we can see from here in the VS code. Also from here, we can switch to the other branch. Back to Master branch, and here we also const dot log and add updates in the script dot js file. Let's also commit with message, update script gs file. Know, this is not good commit message, but this is just for demo. Now back to it Kraken and we can see how branch gets diverge Lovely. Now before doing merge, let's see how we can compare two branches. Select the logout branch and hold safe. And select the other branch which is master. See at the right side, we have difference of two branches, and below that, we have list of files which are affected. If we select the file, then we get file open with changes. I intentionally change here the same line, so we get conflict in line three and let's do merge. Select master branch and right leg on the logout branch which we want to merge. Here we have merge, and we also have rebase. Let's select Merge. See, here we get conflict, and here we get all conflicted files. We select script dot JS file, and here we get this beautiful merge tool. Here at the left side, we have changes from the master, and right side, we have changes from Logout branch, and at the bottom, we have final output. Here, we can select the branches by selecting the check box, and we can also select the both. We can also remove from here, and if we have more than one conflict, then we can see them from here up and down arrow. Now, when we satisfy with our conflicts, then we simply save the changes from here. Now at the right side, we have stage files list. We have also commit message ready. Now we get here two options, Comte and merge, and about to merge. Let's go for Commit and merge. See here at the top, we get T merge Comte. Very simple and easy. Now imagine we get error in our code from this merge. We can also revert or rebase our Commit. Right click on the Commit and select revert Commit option. We'll ask for confirmation for immediate kat. We select yes, C, here we get revert Kumt. Now, if you want to reset the amide to this amid before we do merge, then we can write click here and select reset. Here, we get three options, soft, mixed and hard. We already seen that right. Now here is one thing. Imagine you don't learn the git commands before using Git Kraken or any graphical user interface, then you will definitely goes to the confusing state. That's why I decide to teach you first Git commands and then graphical user interfaces like Git up desktop and Git cracon. Here we go for hard reset and our merge and revert commands are gone. That's how we can work with branches and merging in the Git Kraken. I know this section is little longer, but these are all very important merge lessons. So you did a great job. Give yourself a little treat, listen some music, or play some games, or take a fresh walk. We will continue our journey of kit mastery in the next section. So see you in the next section. 64. Section 05 Working with Team: Welcome to the fifth section of the ultimate Kit course. In this section, we will see how we can work in team using Git. Currently our repository on our local environment, but in real world, we have to work on repository on Cloud. So you might ask, how can we work with other team members in one company? We learned how we can fetch changes from other team members, publish our changes, pull requests, issues, and much more things. I know you are excited for this section, and I am also excited for that. So without wasting time, let's understand how we work in team on single project using Git. 65. Overview of Working in Team: So as I told you, till now we are just working locally. But in real world, we don't work alone. There are many developers working on single project, and that's why we will see the bird side view of how developers work together on the same project using it. So let me ask you simple question. Here is our repository. How do you think other team members can work with this repository? One solution is we host this repository somewhere on server and all developers work on the single repository. This is called as centralized person control system. Now, what if this server on which we had our repository goes offline or goes in the maintenance? Then all developers have to sit and wait for the server get out from maintenance. This approach is not working properly. Now, another solution is for each developer, we give them repository on their own PC or laptop. They are not dependent on any server. They can anytime work on their repository. This is called as distributed Vers and control system, and Git is the example of this distributed Vs and control system. Now you might ask if all developers working on their own system, then how can they collaborate with team members? For working in team, we adhere one centralized repository between all developers. All developers has their own repository, but we have also one central repository which they use for collaboration. Let me explain you this with real world example. Suppose this is you and this is me. Here we are working on one same project, which is, let's say, e commerce application. Now first, we will clone our existing project for both of us in our personal system. Now suppose you work on your task, do some cams, and when you are ready, you push these changes on this repository. Now we have updates on the repository, so I get notified with that. I open this repository and pull the changes in my system. Now my code and the code of this repository become the same. But imagine I get here conflict. I resolve the conflict here in my machine and then push my code to this repository. Now, other developers and you can pull this updated code and continue to work on this project. This is called a centralized workflow and obviously get follow this centralized workflow. Don't get confused. The centralized workflow and centralized vers and control system is not the same. They are different things, just the name are similar. Get follow this centralized work Now, some company use their own private server to host this repository in their company, but maintaining own server is little costly for new companies. So new companies like to use some cloud based server which can host their repository privately. This is cheap and good option for new companies and startup. There are many companies who provide this type of cloud services for hosting repository, and you guess the right. Github is one of the repository hosting platform. We have also Gitlab, Bitbucket, GIT, and many more. But all of us know Github is one of the most popular platform, so we will use Github. You are using any other hosting platform, still, you can continue this course because we are talking about working in team. I really doesn't matter which hosting platform you use. Whatever you do in Github, I think all basics you can do in other repository hosting platform. Now, what if you are working all alone? In this situation, also, you can use Gitub for storing our code as backup. Even 20 to 40% developers use Gitub for storing their line and managing their resume. In future, they don't lost their code. It will available in their Github account as well. It's beneficial for you to learn this. Now from the next lesson, we will see this workflow in process. I'm very excited about it. 66. How to upload project on github: Now before we start creating a new repository, many students ask me, how can I upload our existing Git Project on Github? Let me show you how we can upload local projects on Github. First, we will see uploading project using Github Dektop and after that, I will show you for Gate Cracon. So first, I open Github Dektop here, first, we check our repository open or not. If it is not available in this list, then we go to the file at Local repository and simply browse to that folder and open our project here. Now, if we don't have any changes, then we get here directly publish repository option. Otherwise, we have also that option here after branch option. Here we can see this repository only available in your local machine. By publishing it on GitHub, you can share it and collaborate with others. So click on this public repository button. We will get this pop up which asks for name of the repository. I give it Tas track for Git. If you want to write description, then you can write it here. From here, we can make our repository private or public. If we make our repository republic, then anyone on the Internet can watch our code. One thing is, if you want to collaborate with others, then we have to make our repository public. If we make it private, then we have to pay for private repository for collaboration. If you just want to store code, then we can use private repository. I'm unchecking this box for public repository and simply click on published. See it publish. If you want to verify, then we can check our repository on Github using this button. That's how simple it is. Now let me show you how we can do the same using Git Kraken application. Open Git Kraken application and select our repository which you want to publish. Now, before publishing the repository, we need to connect our Github account with the Get Kraken application. So click on this setting button from here and go to the integration tab. Here we have couple of hosting services by default is sec Github and see here we get not connected. Let's connect to Github. It will ask you to login with your Github account. I login with my account. It will ask us for login or authorize. I authorize and here I write my password and simply open it Crack and application. See here we get our account. Now let's close these settings. We don't need it. Now to publish a repository, we need to first add remote, click on this Cloud icon which is for remote and here we can see we have zero remote. So we can create new. Here, we can see we have Github selected, and it asks for repository name, remote name, which we see in this remote list, description of the repository, and we can also make it public or private. Don't worry, just click on Create remote and push Local Revs button. And then we get success message. We can also view that on github.com. This looks a little bit complicated because we push all our Camts in one go. But in real world, first we create our repository and then work on it. So don't worry about that. Now in the next lesson, we will create a new fresh repository using Github website and learn the section concepts in their repository. So you don't get confused by this master project. 67. How to create a new project on github: So open up github.com, and if you don't have Gitub account, then you can easily create a new account. It's really simple and easy. Also, make sure you verify your email account before creating a new repository. I already logged in with my account here. Now for creating a new repository, click on this plus icon. Here we have New repository, and also we can import repository from somewhere else. Let's go for new repository. Here we first enter our repository name, which we want to give. Let's say, CardwishGt because I have Cardwisname repository in my account. Now here, we can write description of this repository. Next, we have option public or private. As I told you before, if we select private, then we have to pay for working in team. So we select here public. Now here we have a couple of options. You can add ad me file in which we can write long description for our project or website, and we can also select the Getting nor file. Here we have list of languages. For now, we don't want it, and we click on Create Repository. And then we create a new repository. Here at the top, we can see our user name and slash our repository name. If someone asks you to see your code, then you can give them this Github URL. But for that, you need public repository. Otherwise, people will not see it. Now here we have our branch list. Currently, we have only one branch, which is main. This main is same as our master branch. Github called master branch as main. After that, we have number of branch and we also get number of tags. Here we can search specific file. Also, we can create a new file and also we can upload files. Now in this square box, we can see our project. Here we can see our latest Commit. Now you might ask, we didn't commit anything. This is the commit which Github create for creating new repository. Here, we can see Commit has time when it committed and all commits. Let's check this. Here we get the list of commits. We can filter it by user from here and also we can filter it by time. Now from here, we can see commits by branches, and if we want to see more details about commit, then we can click on this. Here, we get the branch which is main. We get user name and we get time also. After that, we can see changed file with two addition and zero deletion and we can see that lines here. Good. Back to our code page. Here we get the list of project files and at the right side, we also get the commit message. In which command this file gets added or changed. We can also view the content of the file from here. There's a little introduction about Github repository. Now in the next lesson, we will see how we can add team members in this repository. 68. Adding team members to project: Now currently our repository is public, but still no one can push commits in our repository. You might say we already make our repository public and still no one can push commits. Why? Public repository means everyone can view our repository, but we need to add our team members as collaborators in this repository. Here we go to the setting option. In the access section, we get collaborators tab. Here we can see we have zero contributors. Let's add one team member to this project. Here we add a member, and we can search team members account using username or full name or email account. I write my second account. This is my new account which I created for this course. If I don't accept your invitation, then sorry about that because I probably don't access this account in future. If you don't have another account, then you can create a second account for this section, or you can invite your friends who also wants to learn Git. This way, you better understand these lessons. See like that user and click on add to this repository. Here, we have one collaborator, but as we can see, we have pending invite. When you add anyone to your repository, Git send them requests for collaboration on their email. If the person accept the invitation, then congratulations. You have collaborator. But that person has also option to reject. That's how we can add team members or collaborators in our repository. 69. Clone Git Repository in our Machine: So as we know, we create a new repository from our Github account. But how can we start working on that repository? Because we don't have this repository in our machine. Let's see how we can add or clone repository from Github to our machine. Go to the code option, and here we get the link of our repository on Github. Copy this and open the folder in which you want to clone this repository. So I am in my project folder, open Gitwsh or terminal in this folder. Here we just write Gate, clone, and we paste our URL. If you're using Windows, then Control plus V will not work. So right click here and see, we have page option and we have also shortcut for that. Now if we execute this command, then gate clone this repository with repository name as folder name. Also, if you want to change it, then we can also do that. Let's say I just want cartwish and hit Enter. C, get clone this repository. So now we have all comets, all branches, literally all details about tet repository. Let's go inside this cartws folder. So change directory to cartwis. Now let's see the coats, so git log, dash dash p line, dash dash all, dash dash graph. Now here we get single command, which is initial command. Here, we can see our head pointer is on this command, but we have two more pointers here, origin main and origin head. Who created this and why? So as we know, headpointer is used to know on which commit we are, and main is our default branch. Now when we clone our project from GitHub, Git create a remote branch and name it as origin. This is not original branch. This is just remote branch. If we try to switch to the branch, then this will not work. We can also check that by using git branch. See here we only have one branch which is main. Now, let me show you something useful. If we write gate remote, then here we get our remote repository which is origin. You might ask, what is remote repository? A remote repository is the project or repository which is hosted on the server like Github or beat Bucket. In simple words, remote repository is, which is not in our local machine. Our current repository is not only in our local machine, it is stored in remote location like on Github. This remote repository, which get called as origin is used for providing information about our Github project. Like on which branch developers currently working on and more. Now, for that reason, Git create two more pointers Origins main or master and origins head. Let me explain you that with the example. Suppose me and you working on the same project and we both clone our project from Github. Now when we clone our project from GitHub, then Git create these two pointers origins main and origin head. Now suppose I work on one feature and push the Cam on our repository. Get move this origin main pointer to this late met on the main branch. So essentially, origin main will tell us where the latest changes happen in our Github repository. So if someone else make another comet, then the origin main pointer move to that comet. You might say, you understand about origins main, which represent the latest changes in our repository. But why this origin slash head is also moving with this origin s main. Honestly, it is not moving. It is on the same branch. Origin s head is used to tell us which is the latest branch is checkout or in simple words, which is the latest branch view or work by any team member. Suppose here we have this feature products page branch. If you are me or any developer switch to any of the other branch, then this origin head will point to that branch. So that's how this pointer works. So to summarize, only head pointer is used to tell us on which commit we are currently working at. Origin Min or Origins Master tell us where the latest changes happen in our Github repository. By this, we can know the latest changes in our Github repository. Origins HAD tells us, which is the latest branch view or work by any team member. Don't worry about this. You all doubts feel clear when you see this all in action. 70. Fetching the Changes: So as we know, this is our Gitub repository, and this is our local repository, which we clone from the github. Now, these two repository are not connected with each other. So when someone puts the changes on this gitub repository, then we don't get that commits automatically. We need to run command Git fadge for getting the new commits in our local repository. Here we need to pay attention. Currently, in our local repository, we are working on the C one comet. Our main, or we can say master pointer is still on this comet. But as I told you in the previous lesson, our origin main pointer will move forward because it represents the latest changes in the remote repository. By using Git patch command, we get decommit, but our master or main pointer is still on our C one commit. So we get decommit in our history, but our working directory is still unaffected, and by that, we don't get any conflicts. Now, if you're comfortable to apply those changes on your working directory, then we can run git merge, and this pointer name, which is origin Min. So here we don't have any diverse branches. What type of merge Git perform. Absolutely right. Git perform pass for or merge. And if we get any conflicts, then we solve them as we are solving previously and then done. Let's say this Git patch practically. So on this browser, I log in with my other Github account. And in this machine, I have my original account, which is God bless you. Here we only have me file. So let's change in this file and simply commit it. Click on this file, and from here, we can edit this file and change this text. This is for second commit and simply commit the changes. Here, we can write the commit message. I leave it as it is. Here, make sure we select Commit to main branch. We can also create a new branch from here with this commit. But we will see this option in upcoming lesson. Simply click on Commit. Now back to our code window, see, here we have two comets. Now if we see in our local repository, then here we get only one met. Now let's see how we can fetch repository from our remote repository. We write git fetch, and then we write our remote name which is origin. We don't write anything, then by default, Git takes origin. See, it is patching. Now let's check our history. See, we get to comets, and we can also see origin main and origin head is moved to this comet, but our head is still here. Now, let's see how we can add these changes in our working directory. Suggest we write git merge, and we write our pointer name, origins main. And we done. See here we get fast for our merge and we can also see in our history headpointer is moved to our second command and we also open IDM file in VS code, then we get the updated RDM file. 71. Pull the Changes: In the previous lesson, we see for getting latest changes from the remote repository, we need to use it patch command and then for adding changes in our working directory, we need to merge it. As we can see, this is two step approach. We can do this in single step also, and do you know by which command it is it pull? Suppose we have these amds in local repository and remote repository. Here we commit in our local repository and here other team member also add amid to the remote repository. Now if we do git pool command, then Git add this sit commit in our local repository and origin Min Pointer move to this amid. Now git merge these both changes and make a new coat. Now many developers don't like this approach because we can see it is creating new merge kamit and also we get diverge commands. The other solution, instead of doing merge, we can also perform rebasing. So we can run git, pull, rebase command, and that will rebase our committee to this origin slash main commit, and that's how we get linear and clear history. Now, which is the best option for pull Merge or rebase? Honestly, this really depends on our situation. Most probably your manager will tell you to use merge or rebase, don't worry about that. Personally like to use rebase instead of using merge because our commit history will stay clean. So let's see this in our repository. So for pull request, we first need to commit some changes in our local repository, as well as in remote repository. So I open our local repository in the VS code and create a new file, let's say, scrap dot js, right here, console dot log. This is scraped file. Save the changes, and let's commit these changes. Back to Git Bash it Ed period, c staging and Gitatm createscript dot Jsfile for JavaScript. Now let's check our history. See, here we get three Camits and our head is moved to our latest amit and origin main and origin head is still on this Commit. Now let's make Cait in our remote repository. Head over to second account. And here I create a new file from here, and here we write our file name. Let's say plans dot TxD. Physically, I will write plans in this file. So step number one, create a basic website layout for this project. Now, let's commit this, so commit changes. I leave this commit message as it is, and go for Commit. Done. See, here we have three commits. Now back to our Git Bash. Here we run git pull command, so this will add our remote repository commit in our project and then merge it. It will ask for commit message. I don't want to change it, so close this. See, merge is complete. Let's check our history. See, here we get the merge commit, and also we get the divers coats. Now let me show you how we can rebase with pull. Before that, let's undo this merge commit. So git reset, d dash hard, and we want to go one step before head. So head till one. Check our history. See, we reset our merge, and we get this separate branch. So let's run git pull, rebase. Basically, we are telling Git to rebase our current commit to the origin main pointer and see we get success message. Let's check our history one more time. See, we get linear history, and this origin main is move here. Now in the next lesson, we will see another very useful command, which is push command. 72. Push Changes to the Remote Repository: Now, currently, in our local repository, we have four comets, but in our remote repository, we have only three kamets. We don't have this one at. If we want to add this kamide to the remote repository, then we have to use Git push command. Now, as we know, this main will move to our latest kamid also in our repository, origin main will also move to this comet. We write it push. Here, we have to write our remote repository name which is origin. After that, coat we want to push, which is main. Currently, we are also on main, so we can remove this main also we can remove origin because that is default remote repository. Now sometimes it can ask you for your Github user name and password before pushing the code. You have to write it when it asks and we're done. Let's check our history. See here our origin Min is moved to our main command. If we want to verify, then we can check our GitHub page. See here we get four amets and if we check it here, then we get Camets. We successfully push our code to our remote repository. Now let me show you another situation. Suppose here we have three gametes and in remote repository, we have only two ametes. Now before we push this camete to the remote, our team member push another kamit here, if we push our code, then our push command will fail. Can you tell me why? Right. In this situation, our local repository history and remote repository history is different. If Git still allow us to push, then we can lost this team member commit. And that's why Git fail our push command. Now sometimes many developers use Git push F to forcefully push our code. So when we run this command, then remove this amit and add our amid in remote. But that's not a good practice because essentially, we are removing our team members work. So if you don't have any main reason, then in my suggestion, don't use push force. Now, what is the solution for this? So if our push request gets fail, then first, we do pull request. This will add this gummit in our local repository, and then by using merge or rebase, we can add changes in our amid and then push our changes to remote. So now our local repository and our remote repository history are same. So the most useful commands for Git is git pull and Git push because these two commands are used a lot to work with team. 73. Pushing the Tags to Remote: Now, suppose here at this stage, our application is ready for version 1.0. Do you remember the command for adding tags? Don't worry, you can see my Git chit sheet. So here we write git tag version 1.0. This command we add tag to our current commit. If we want to give this tag to specific commit, then we can write here that pointer or commit has. For now, let's add tag to our last commit. Let's verify this. Git log. See, our last commit is marked as tag version 1.0. Now here, I want to tell you something. This tag is only visible in our local repository. This is not visible on Github remote repository. So how can we push our tags to remote repository? For that, we have to write git push. Here we write our remote name which is origin. Here we write our tag name which we want to push, which is person 1.0. Done. Now let's verify on Github website, we get our tag or not. See, here we get one tag. Let's see this in more detail. Here, we can see the author name, time, and we can also download the full source code from here. I use it a lot when I'm working on big projects. So that's how we can push tag. Now suppose we want to remove this tag, so we can write the same command here, we add dash delete. See, it's successfully deleted. Now, if we check our history, then we can see tag is still here because that command just remove tag from our remote repository. If we also want to remove this tag from local repository, then we write Get tag, D, we write our tag name. See, it is removed from our local repository also. 74. Create Releases for Github: So in the previous lesson, we see how we can give tags. But here is one thing about tags. In tags, we can't describe what is inside the version 1.0. So if a new developer join our team, then we have to explain him or her what is inside this version. Otherwise, we have to tell them to see all the changes. But don't worry, Github provide very useful solution for this situation. In Github, we can add releases to describe what is inside this version. So we go section, and here we have releases. Currently, we don't have any release, so we create a new release. Now at the top, we have option for selecting the tag. Currently, we don't have tag because we delete it in the previous lesson. Right here, our tag name verson 1.0, and we create a new tag. After that, we select a branch, which is main. Here we can write the title of our release. Mostly, we write the same name as our tag name, but you can also give your name. It's totally up to you. Now in this text area, we can describe our changes and features. So first, we select heading from here and right here, our heading, let's say, release details. You want to see preview, then we can also see that. Also, we have many options. Let's add bullet points for details. Let's create basic website layout, fix the layout bug and design homepage. Let's see the preview. See, we get our details. Now at the bottom, we can also attach binary files to this version. If you have compiled version of your application or any binary file you want to add, then you can edit here. If your release is not ready to publish, then we can check this release as pre release. Team members know this is not for production ready. Now, let's suppose we are ready to release. I uncheck this box and click on publish. See here we get our new release and we can see details, some basic information, and as our text, we also get here our source code. Release is very beautiful feature for working in team, and also we can use it as the documentation of our application journey. If we go to the homepage, then at the right side, we get all releases of this repository. So one thing I want to tell you is release is the feature of Github, not Git. We can only see releases using Github, not by command line. Now in the next lesson, we will see how can be working with branch in team? 75. Working with Branches: Now let's see how you can work with branches in team. Here, I create a new branch with kit switch C feature slash ad to cart. Now let's check our branch list. C. Here we get two branches, main and Add to Cart. But this new branch is only available in local environment. Now, if our team members wants to work on the same branch, then how can they do that? For that, we have to push this branch to our remote repository. Or pushing what we use, right. We use git push origin mean to push changes to the origin. But here we get everything up to date because this command will only push codes to the remote, not branches. We write here, gate, push, here we get this petal error, which is saying the current branch feature slash head to card has no upstream branch. Also it is giving us suggestion for solving this error. This command will set this upstream branch on our remote repository origin. But wait, what is this upstream branch? What will happen if we set upstream branch? Setting upstream branch means building a connection between our local branch and a branch on the remote repository. Let me explain you with the example. Currently, this is our branch in our local repository. If we upstream our branch, which means we build connection to, let's say, a branch called Origin slash feature slash Ed to card. Don't worry, this is just for example. If you push your branch, then it has the same name as you give it. Now these both branch are connected with each other and we can also say upstream branch also referred as remote tracking branch. You might say, we understand setting upstream branch is building connection between local and a branch on remote repository. But why we need this connection? What is the benefit for doing this? First benefit by setting upstream branch is Git know where to post the changes from the local branch. So if we push the changes from the local branch, then by this connection, get know where these changes will add in the remote repository, and also same apply for pulling the changes. If our team member push something to this branch, then if we pull that changes, get knows from where it needs to fetch changes. So it will fetch changes from this remote branch origin slash feature, slash add to card to our local branch. Overall by setting upstream branch makes our workflow easy to push and pull changes between local and remote repository. Let's see how we can set upstream branch for our local branch. And here, Git also gives us solution. Before that, let's see our current local and remote tracking branches. Basically, we see upstream branch name. Git branch, V C, here we get Min and its upstream branch is origins main. But for features head to card, we don't have any upstream branch or we can say we don't have remote tracking branch. If we want to see the list of remote tracking branch, then we can also have command for that. Git branch R for remote tracking. See, currently, we only have these two pointers origins main and origin slash head. Let's set upstream branch or remote tracking branch using git push, dat, upstream, or here, we can write shortcut which is dU or upstream, here we write our remote name which is origin. And after that, we write our local branch name, which is feature slash head to cart. Remember, we have to write this command only first time we push our branch. C, branch is pushed. Now if we check our upstream branches, get branch V C. Now here we can see upstream branch for our local branch, which is origin feature, slash head to card. Also, if we run git branch R, C, remote tracking branch is added. Let's also verify it on GitHub. Basically, we have one branch, refresh the page and see, here we have two branches. Now we can start working on this head to card branch, same as we are working on our main branch. When we want to push our gammas, then we can push it on this branch and other team members can see that push changes. If we want to remove this link between local branch and remote tracking branch, then we can write command like this it push D for deletion. Here we write our remote name, which is origin. And then we write our branch name which is feature slash head to card. So now we remove the remote tracking branch. If we run git branch, R, then C, again, we get these two pointers. And if we run git branch, VV, then here we can see we get origin feature slash head to card is gone. Let's also remove this branch from our local repository. For doing that, we have to first switch back to the main branch. Here we write Git branch D, and here we write our branch name feature slash t to card and done so that's how we can publish branch on our remote repository by setting upstream branch. Now in the next lesson, we understand in real world how team members working with branch. 76. Real World scenario for Working with Branch: Let's understand working with branches using real world scenario, you can understand more clearly without wasting time. This is not the example, this is real story. When I joined my first company, I got opportunity to work on one feature, which is working on homepage design. This feature, I have to work with Unati and she is the existing employee of that company. We have to design homepage for the company website. That company was building website like stackoverflow for problems and solutions. She told me she works on the question card design, and I have to work on header, footer, and sidebar section. First of all, she created a new branch called feature Ss Home Page, and she started working on design Qi card. But here I am clueless. What is happening here? How can I work with branch? I know the basics of git, but I don't have real experience. I first clone the project from the Github and first, I run the pull request for getting the latest changes from the remote repository. I also start working on the same feature Sless homepage branch. We are both independently working on the same branch. Now she done with her design, so she commit to code and then push the changes to the remote repository. Now she tell me that she pushed the code. Here I again, pull request and get the latest changes and merge it with my code. Now after some time, I'm ready with my designs, so I push the changes and inform her. She runs git pull request and merge it with her code. After 5 hours of doing this pull and push, we are done with homepage design. Finally, I push all changes and tell her. She pull all the changes on the branch, and if she gets conflicts, then we contact with each other and resolve the issue. Now, this code go for testing and our manager review the final code. If all okay, then this code merge in the main branch or rebase or squash kms, whatever best option. Then this feature slash homepage branch drop from the remote. As we remove the branch from the local repository. That's the scenario of working together, or you can see how we can work on same branch as team. 77. Practical Showcase of Working with branch: Let's see the practical showcase of working with branches. You might ask why I am so focusing on working with branches? Because this is the most used and little confusing concept for developers, and that's why I'm showing you step by step. After completing this course, you master working with branches. To simulate this, I will show you both BC work. I work on my PC and also I will share screen from nati PC. This is nats PC. Now here in this project, C creates a new branch. Previously, we have seen how to create branch using commands, but we can also create branches using Github. Or open this branch, drop down, and from here, we can create a new branch. Let's say design Homepage and select, create a branch from main and done. We create our new branch and see here we get this branch is upto date with main. The branch is on the remote repository. We need to fetch it in our local repository. So here in this terminal, we write git fetch to fetch this branch. See, here we get new branch design slash home page. Now let me show you something. If we write Git branch, see, here we don't get the new branch, but we can see Git find this branch in our remote repository. Here, we write Git branch R. Then we have this remote tracking branch. When we run Git fetch, then we always get the remote tracking branch. Now we create a new private branch in our local repository and then link it with the remote tracking branch. For that, we write it switch, C or create here we write our local branch name, whatever we want to call. We can call it anything, but most of the time, we call it same as the remote tracking branch name. So we don't need to remember it. Design homepage. After that, we have to write our remote tracking branch name, which we want to link, which is origin Design homepage. We get the remote tracking branch name here. Now if we write git branch VV, C, here we get the branch, and it is also linked with the origin design slash home page. When someone else create a branch and push branch on repository, then first, we have to run it fetch command. By that, we get the remote tracking branch, and then we have to create a local branch and link it with our remote tracking branch using Kit Switch, C, local branch name and remote tracking branch name. Now here we can commit our changes and push it to our origin. So I open this repository in the VS code, and here I create a new file called index dot DML, and just add here boilerplate code. Save this and simply stage the changes and commit these changes. Gated M, create and index dot DML for home page. Let's also push the changes to the remote. Git push, done. Now let's see how I work in my screen. Here we have our repository in my PC. If we don't have, then we have to clone our project. Let's first get all it is changes using git fetch. If we check our log, see, here we get new branch. Now I switch to this branch by using Kit switch Design slash home page. Now before we start working on our code, it's always better to pull changes from the remote. But here we just fetch the changes so we don't need it, so we can directly start working on this. Here I do some changes in script dot js file, save the changes. Now let's imagine I completed my work on this branch. Let's stage the changes and also commit the code with commit message, complete working on script js file, I push the changes, Gate push. Now, as I told you previously, closing this branch is the responsibility of nati. Let's back to the nati spec. Here, see first, import my changes by using Git pull. Good. Here we get fast for our merge. Let's check our history. Here we get to commits. Now we have our branch code ready and also our design homepage pointer is ahead of main branch. Here, we have to merge our code in main branch. We have done this so many times, here, first we switch back to the main branch. After that, we write gate, merge, design home page. See, here we get fast for our merge because we have linear branches. But here we don't get conflicts. Because this is just a demo. Most probably every time you will get conflicts, and we already know how to resolve conflicts. So you have to resolve it with your team members. Now, let's see here our log. We can see now our main pointer and design homepage pointer is on the same mit. But origin Min is on the previous amid. So we have to push the changes on remote repository and how we can do that, right, by using Git push. Now let's check our history again. Now origin Min is on the same gait. Now let's check this also on Github. Go to the gametes. See here we get our latest Camite which is Merge Gamit. Now as our design homepage branch is merged in the main branch, we can remove this design homepage branch. Otherwise, it will create confusion. So get ph D origin and design homepage. C, branch deleted from the remote repository. But if we see the branches, C, here we still get homepage branch, so we have to also drop it. Get branch D Design Homepage. C. Now our local branch is also drop. Now back to my PC, first, I will pull the changes for getting the merge commit. Now we both have the same commit history. First, let's check the remote tracking branch using Git BanchR. See here I'm getting the origin design slash home branch. So far removing the remote tracking branch, which are not available in remote, we write Git remote Prune origin. This command will remove all remote tracking branches which are not available on remote repository. Now let me check local branches. See I still have here, I have to also drop the local branch. Again, git branch D Design home page, and here we get error, cannot delete branch design slash home page because we are currently on the Design slash home page, we switch to the master branch. Gate such as to use the git pull command for update local branch. See here we get fast for our merge, and if we check our history, see here we still have this design homepage branch. We run git branch D Design slash home page, and it's delete the branch. That's how we work with branches in team. You get a little confused, then don't worry, let me recap this portion. First, we create a new branch and then for pushing that branch, we have to set upstream branch. So it knows which local branch connected to the remote branch. After that, we can start working on the branch. If we want to push something, then first we commit that and then we can push it to the origin. But before doing push, it's good practice to use pull. We get the latest changes and after completing the commits branch work, we merge it with the main branch and then remove the remote tracking branch and also local branch. If remote tracking branch is already dropped by another team member, then we have to run git remote, Prune origin and we are done. 78. Creating Pull Requests on Github: Now, suppose you are working on one branch and in the between of the code, you want to get some suggestions from the team members. Then on Github, you can take suggestions or open discussion for the specific topic. In this situation, we can create pull request for opener discussion on our code. Ask for suggestions or review from other team members. Let me show you that practically. Here is the NathiPC. Let's create a new branch and push changes in that branch. First, we write Git switch Design slash Q&A Page. Let's open this code in the vias code. Here in the index dot SDMLFle in the body, I add main tag. Inside this, I add Du in it, another DU and here H one tag. This is question one. This is just a demo. Save this and let's comm and post these changes. In our terminal, we write tight AM, adding Q card. One. Good. Now we have to push these changes to our remote repository. And how can we do that? We can write gate, push. But see here we get fatal error. Can you tell me why? Yes, because we didn't set upstream branch. Or in simple words, we don't link our local branch with the remote branch. Here we simply write Git push u origin, here we write our local branch name, which is Design Slash Q&A page and done. Here, we push our changes with setting Upstream branch. Let me open this account in the GitHub website. See on the homepage, here we get Design SQ and page, H DSN push, and we also get D compare and pull request. Here we can open discussion for this Q&A page branch and contributor can give some suggestions or discuss the code. Also, we can create pull request from this Pull Request tab. Click on New Pull Request. Now here, we can select two branches for comparing changes. Most of the time, we select main branch as base branch, and here we select our Q&A page branch. See, here we get the commits on this branch. We have one commits, one file change, and also we have one contributor. Here we get a list of commits and below that, we can see the changes in our files. Here we can also select for split view, so we can see before and after very clearly. Now let's open discussion for this branch. Click on Create Pull Request. Here we can write our discussion title. Let's change these to suggestions for question card phon. Below that, we can describe what we want to discuss, what we want to fix, et cetera. Let's say, first we add title suggestions needed, and after that, bullet points, suggest some semantic tags for card and overview this body code. Now we can simply create pull request or we can also draft it. Let's go for Create pull request. See here we are in the conversation and this pull request status is open. Now, how can other team members know we open this discussion? For that, we have to add them in the reviewers. Click on this gear icon, and here we have the list of contributor, which we added in our repository at the beginning of this section. Se like this account. Now, the moment we select the user, Github send an email to this user and tell them have new discussion. Now let me switch the window and show you how this team member can review our code. So this is my original account. We go to the pull request and see here we have this discussion. Open that. See at the top, here we get this message. This user requested your review on this pull request. So click on add your review. Here, we get a split view of this changed file. If you want to see the whole file, then we can click here, Expand All. Now here, I have a couple of changes which I like to suggest. First one, in this main tag, we can go like section article, and then H one tag, not the simple de Also I want to tell at class for question card article so developers knows this is question card. Here we can see before each line, we get these plus icons. By that, we can write review for each line. But currently, I just want to tell text hierarchy and class name. So I click on this plus icon, and we write our review here. So I add bullet point first, add semantic tag, main section, article, and H one, and after that, add class equals to question underscore card to the article tag. And simply start the review. See here we can see the review and details and currently it is in pending state, and we simply finish this review. Here, we have to write basic description for our review. So we can write these are the suggestion for this code, make the changes, and push them. Now at the bottom, we get three options. First, we can submit this as command. We can set approve and we can request the changes. Currently, we are requesting two changes, so we can select that and simply submit the review. See, we are on the conversation tab of this pull request, and from here, can see what is happening here at the bottom, we get our review, which is just submitted in very systematic way. And below that, you can see we have changes request. A at the right side, we have this icon, which informs this user at request for changes. So now let's again switch to the nadis account from which I started this discussion. First, we did the preview from the conversation tab. And then we make changes in our code. So I open index dot SDMLFle. First, I change this first due to the section and second DU to article. If you wonder how I am changing opening and closing tags together, then you have to install Autor nam tag extension in your VS code, highly recommended. Also, we need to add here class to question underscore card. Save the changes, and let's commit these changes. So GtmtAM semantic tags, and class name update. I know this is bad coommit message, but it's just for demo. Then let's also push this. Now as we done with our changes, we need to tell that member to view our changes and verify it. At the right side, we have this re request review option. Click on that. This will again send email to that user and tell them to see updates. I again switch to my account, and here I can see this user requested your review on this pull request. Click on add your review. Check our changes and if we are not satisfied, then we can again write review and submit that review. Here, we satisfied with the changes, then we can click on viewed and simply click on these review changes. Here, I write, perfect, that's merged in our main branch. From bottom, we can select, approve, and submit review. See here we get changes approved, and this discussion fulfill its purpose and we can see at the top, we have the approved changes status. Now at the bottom, we have options for merging this pool request. Now here is one debate which developer do when it comes to closing pool request. Ask who should merge this pull request? The one who started that pull request or some reviewers should merge pull request. Some developers go for this first option because they think the person who start pull request knows more about that. So he or she who created this pull request, they have to merge it. So some developers says the person contribute to MR is the reviewer, reviewer should merge. Honestly, you don't need to worry about that. Just simply ask your team members or manager about it because some companies follow first option and some follow second. So do as your team members suggest. We can merge this pull request from here and we get three options for merge, simple merge, squash and merge, and rebase and merge. We already know this option, so let's go for simple merge, confirm the merge. See, we get pull request successfully merge and closed. Now we can remove this branch from here. We can restore the branch. Now let me go to the nathiPCF switch back to the main do gate, pull for getting the merge commit. See, we get fast for our merge and if we check our history, see, here we have Q&A page branch and also remote tracking branch. Have to remove this branch from local and also remove remote tracking branch. So this branch is already removed from the remote repository, and we want to remove it from our local repository, and how we can do that. We can write git remote, prune origin. Now let's remove this local branch also. Git branch D, Designs Q&A page and done. You can see if we use any Git commands two or three times, then we don't get confused by that. As I told you, this is all about practice. I know this lesson is little long, so you can take five to 10 minutes break, get some fresh air, and after that, continue this course. 79. Resolving Conflict while Pull Requests: Previously, we have seen when we are doing merge in pull request, we don't get any conflicts. But what if we get conflict? One way is we can use VS code, but that is little long way. If we are doing merge in our local branch, then we have to use VS code. But also, we can resolve conflicts using Github. It is only useful while we are merging pull request. Let's say this. First, I create a new branch from Una this PC and make one gait and push that Kat. Get swish C features Homepage. Here in index dot SDMLFle, I change the title for demo to home page title. And also change the first line in script dot Gs file. This is script for home page. Save the changes, and let's commit this Gtms AM, Update title and script for home feature. Now, let's push this branch on Github. Do you remember that? Right, use Git push for setting Upstream branch origin feature Slash home page. Done now to create conflict, I open Github account from my PC and simply open index dot STMLFle we select Edit and change this title to title in main branch. Let's commit the changes and continue with this commit. Now let's create one more conflict inscript js file. So we again change the first line to the script per main branch and come interchanges. Now let me create a pull request. So head over to Github and we go to the pull request section. Here, we create a new pull request. Base is main branch, and we compare it with the feature SLS home page. See, here we cannot automatically merge. Don't worry you can still create a pull request. Let's create a pull request. Here it automatically pick Commit message, and we can write description for the pull request, pull request for feature slash home page, and create a pull request. See, here we get this branch has conflicts that must be resolved. So here we can use command line to resolve the conflicts. Also, we can do that using Github. We simply click on Resolve Conflicts. Here at the left side, we get the list of files which have conflicts. Here we can see the conflict. We have already seen these pointers. I want to keep this home page title. Se conflict is gone from this file and click on Mark as resolve for this file. Now for the next file, here I keep this main branch code. See here are all conflicts are gone. We can also mark this file as resolve and simply commit merge. And see, now this branch has no conflict with the base branch. Also, if you want to add reviewers, then we can also do that, same as we done in the previous lesson. Now we can merge pull request, and confirm merge. That's how we can resolve conflicts while creating merge request. 80. Creating Issues in Github: Now in Github, as we have pull request feature, we also get issues option. Again, this is the feature of Github, not Git. What is these issues? Issues is like a sticky nodes we use in our book. Sticky nodes are used to write nodes, correct something, or write questions, et cetera. Same as we can use issues to track task, bugs, or we can also discuss about our project. Let me show you that. So click on New issue. Here, we can write our issue title. Let's say, discussion on card features. And here we write our description for this issue. Let's discuss about the features of question card for this project. Here we can also attest the demo image of our card basic design. Attachments are very useful. If we are creating issues for solving the bugs, then we can attest the screenshot or screen recording for showing the bugs. At the right side, we can assign the issue with our team members. For now, I just added my another account. After that, we have labels. Github has so many relevant labels for almost all types of issues. See here we get bug documentation, duplicate, enhancement, good first issue, invalid, question, and Vance fix. Also, we can create our own labels. Let's edit these labels. And create a new label. We can give name discussion. From here, we can change color. So let me try something. Yeah. I like this one and create label. Now back to our page. And I select this new label. Here we can also link our projects. Also, currently, we don't have milestones. We will see milestones in the next lesson. For now, don't worry about that. Also, currently, we don't have pull request, otherwise, we can also connect issue with pull request. And when we merge that pull request, then all connected issues will close automatically and let's submit new issue. See here we get this issue open. Now assigners will comment on this issue and discuss about what they think and set their suggestions. Now, after completing the whole discussion, we can also close this issue. That's how we can use issues using Github. That's why developers love Github. 81. Adding Milestones in GitHub: Now, sometimes in our project, we want to create a milestone. Milestone, we can see as the short term goal or long term goal, which we want to complete in particular time. For example, in our project, we want to add user authentication feature. So we can create a milestone and we can set date for completing this milestone. In this milestone, we can add various type of issues like design login page, design signup page, plan for password reset options, et cetera. Suppose I complete this design login page issue, so I can mark that issue as close, and in our milestone, we get 33.3% progress. When all issues are solved, which are connected to this milestone, then our milestone flows automatically. This is very useful for planning, organizing, and keeping track of our projects progress. Let's see how we can create milestone in Github. Here we are on the issue section. At the top, we get the milestone option. Currently, we don't have any milestones, create a new milestone. Here, I write title for this milestone. Let's say user authentication. Here, we can select the approxtate when we complete this milestone, and at last, we can write description for describing this milestone. So implement user authentication functionality, including signup login and password reset features, and we create milestone. This is our milestones list. Here we have basic details about milestone and here we can see our progress. Now to show you progress, let's add one issue in this milestone. Go to the issues and create a new issues. Add here title, design, login page, add assignersO we can also assign our own self. I select label to enhancement and from here, we can select milestone. See, here we have user authentication milestone. This is another way to add issues in milestone. So for now, I just submit new issue. Now back to issues page. Here, we select our issues from all issues which are open. And here we have milestone option. Here we select user authentication milestone and see, here we get our milestone name. Let's see our milestone. We can see we have one open issue in this milestone. So clic on the milestone and after completing the issue, we can select this and mark it as close issue. And see here our milestone is 100% complete. That's how we can use milestones in Github. 82. Workflow of Working on Open Source Project: Till now we see how we can work on our project with our team members. On Gitub, we can also work on open source project. Let's see the workflow of open source project. For example, here is one open source project in which you like to contribute. This is the project on my Gitub account, but you can't directly start working on this project because you are not added as a contributor, and that's why you also cannot push your code on this project. So what is the solution here? How can we start working on this project? First, you have to add that project in your own Github account. This is called as creating Fork. Now here we have complete access for this repository. Now when you are done with your contribution, then you can push your changes to your repository. After that, you can create a pull request to merge your code. And the moment you create a pull request, Github, email me that. Someone create pull request for this open source project. I check your code. If I want to give you some suggestions, then I will give you and then when I'm satisfied with the code, I can merge that code into my project directly from your pool request. Here, you can't merge the changes in my repository because only I can push the changes to my project. To summarize, first, we find open source project on which you like to work. Then we fork that repository. This will add that open source project in your Github account. When you are done with your changes, then you can push the changes on your project for final review, you can create pull request. Now, author of that request checks your code, give some reviews about your code, or suggests you to do some changes and then simply merge that code into his or her open source project. That's how we can work on the open source project. Now in the next lesson, we will see this practically. 83. How to work on Open Source Project: So when we want to contribute on some project, you can search here the repository. Suppose I want to work on searching functionality in react. So I search here react search. Here, we get the list of repositories, and that's how we can find repository. And in that repository, developers added some issues which they open for discussion or contribution. You can work on that specific issue. Here, I select my own project, which I created three years ago. And here we can see I also open one issue for this repository. Now, this repository is committed by my old account, not by Cod bless you account. And in this browser, I logged in with Cod blessu so I can contribute to that project. Now, first step to work on open source project is we have to fork the repository in our account. So at the right side, simply click on this fog icon. Here we can change these details if we want to and simply click on create Fog. See, here we get the copy of that repository and we can see it fog from the original repository. Here we can see this branch is up to date with our original repository branch. Now we can close this repository in our machine and start working on that. Let me show you that so you don't get confused. Copy this repository link and open terminal where you want to add this project. Here we write Git clone and paste the repository link. Good. Let's go into this folder and create a new branch here. Get switch as C design Home and open that in VS code. Here, I do one little change in app dot JS file. Save the changes, and let's commit these changes. So Git, come 8:00 A.M. Update the F file. And for pushing this branch, first time we write Git push U for upstream origin design home. Good. Now when we are done with our updates, we back to our repository, refresh the page. See, here we get this design home Harris and push. So we can compare and pull request, same as before. But here is one little difference. We are comparing our design home branch from our fog repository, and we compare with this original repository master branch. Here, we can write a title for the pull request, and also we can write description. For now, I directly select create pull request. See, here we created pool request, and in this, we have no conflicts. But here is one thing. We can't merge this pool request, only the maintainer or owner can merge it. So from my old account, I can accept the changes and implement it in that main repository. Here is my old account, which is the owner of that repository, and here we can see pull request. Open that and here we can see that cot from bottom, see here this account, get merge, pull request, so merge pull request, and confirm merge. That change is added in the main repository. That's how we contribute to open source project. 84. Sync Local & Fork with base repository: When we fork one repository, this fog repository is not really connected to the base repository. So when we are working in that fog repository on this base repository, someone can commit changes. So at that time, we have to sync fog with this base repository. But how can we do that? It's really simple. So we go to the fog repository. See, here we are getting this branch is two branch behind from the base repository branch, which means there are two comes happen after our current code. So at the right side, we get the option sync fog. Here, we can compare these changes or we can simply update branch. Then we have up to date branch here. So we can simply fetch it in our local repository. So run git, fetch. See, here we get new commit. Now we can simply merge it with our master commit. First of all, we will switch to the master branch. Good. Currently, we are on Master branch, and we write git merge origin master. And done. We have all changes in our local repository as well as fog repository. That's very easy and that's all about working on open source project. There is no rocket science for this, we have to practice it two to three times. 85. Collaboration tools in VS Code: Now let's see some collaboration tools in VS code. So in our project, here we can see we are currently at the master branch. Let me switch to the other branch. Now let me show you how we can push change to our remote. So in Read Me file, I change this title, let's say, getting started with VSCode. Save this, and now we go to the source control. Write commit message, updating read me for VSCode, and Commit. Now here we can see we get sync changes option. And if we hover over that, then it says, push one commit to origins Design slash home branch. So from here, we can also push. Also, if we click on these three dots, we also get the push option. With that, we also get pull, clone checkout, fetch, and much more interesting options. Example, if we go to CDs, here, we can do normal Commit, commit only stage files, commit, undo the last commit and also about rebase. We have changes, pull, push, branch, remote, stairs, tags, and almost all options which are often used in git. I don't want to bore you by showing each and every option. We already seen these options using command line. So here, I do simple push. And done. We post the changes. I use these options when I don't want to open terminal. Otherwise, I like to use command line because that is more clear for me and also I don't like to use mouse when I am coding. I don't know why. If you want to use these options, then it is also fine. It really depends on your personal choice. I am no one to tell you use this or don't use that. Choice is yours. Also in the source control panel at the bottom, we can see our comets, branches, remotes, stasis, tags, work tree, and at the bottom, we get the list of contributors of this repository. Also, from here, we can add contributor. If you don't want to use Github website. 86. Collaboration using Github Desktop: Now let's see collaboration options in Github desktop application. So here I also change the Read Me file title to getting started with Github desktop application. Save this and let me commit this with message, update, read me file for Github Dextop. Good. Now, let's move to the Github desktop application. Currently, I don't have our fog repository project open in Github desktop application, so I have to open that. So I go to the file, add Local repository, choose my folder path, and add repository. See here we directly get push origin option. Also you can open this project on Github using this button. Very useful tool. Now at the top, we have current repository. After that, we have current branch, and then we can see we have push to origin button, and below that, we get details about fetch. In real world, when we are ready to push our changes, it's good practice to first pull changes from the origin. So at the right side, we have button. See here we get patch origin. Click on that. And if we have changes, then we get those changes in our repository. And if we have conflict, then before pushing, we can resolve our conflicts. And by that, we don't need to again push Merge kat. Using this practice, we can clean our Cat history. Now at the top, we have repository menu, and inside it, we get many basic options for git, like push, pull, fetch, remove, and at the bottom, we get repository setting. I only like this option because here we can easily change our remote repository. So these options are very similar in VS code. Funny thing is VS code has much more options than Github desktop application. And that's why I tell you Github desktop application is simple, basic and beginner friendly application. Let's simply push to origin and done. Now here we can see we can preview pull request, and we can also create pull request. And when we create a new pull request, then we can see that in our repository page. Now we will see other options in the next lesson using Git crack and application. 87. Collaboration using GitKraken: Now let's see collaboration tools using Git kraken. First of all, in Git Kraken, we have to open that fog repository because currently it is not opened. So go to the file, OpenRpo here, we select opener repository and select our repository folder. Now here we can see currently we are on Design SlesOme branch. At the left side, we can see local branch name, remotes, currently active pull request, which is zero. We can also create pull request from here. After that, we have issues, select here Github, and we get the issues. Here, we can also create a new issue and after that, we have much more options. Now let me show you something really cool. Here we have repositories. After that, we have list of branch which we already see in the previous section. Now after that, we have a couple of buttons which are very useful. First, we get undo, which is for undoing the last coat. If we hover over that button, then we can see what that button does. So we undo the last amid. See, here it's gone. Let me redo that. After that, we have pull button, and here in the pull, we have many options. Fetch all, pull if fast forward is possible, only fast forward and rebase. Now, after that, we have push button and this branch button for creating branch from this current selected commit. Now here, we click on this branch name. We can see, we also get pull request, push set upstream, which we set for pushing branch first time. Also at the bottom, we can start pull request for this branch and much more options. Here, we don't get much option because we are working on the fog repository and we can't directly push to the base repository. Let's start the pull request. Here, we can select our branch from our both origin. From our fog repository, Design Home branch and compare it with our base repository Master branch. Now we write here, pull request title, so updating read me in design home. Here, we can also write description, and from here, we can simply create Pull request. Also we have option continue editing on Github and see here we get the Github website. Simply click on Create Pool request. And done. If we have conflict, then here, we can resolve this conflict. And after that, from the base repository, we can merge these changes to base repository. We already seen that right. Now from my second account, which is author of this repository, we go to the pull request. Here, we don't have any conflicts, so we can merge it with branch. And done. That's how we can work with corabation tools in it Kraken. But here is my personal opinion. If we know what is push, pull, setting upstream, merge, rebase, and all the terms, then using git command line is much easier than using graphical user interface. In GUIs, we can clearly see the history. But for these options, I personally think command line is much better option. Can open our chit Sheet anytime and write that command. Simple as that. We don't need to find options or we don't need to open Git Kraken or Github desktop application in background. Instead of that, we can simply use Git Bash terminal or VS code terminal. So that's all about collaboration in git. I hope you learn a lot from this section. After this lesson, I added Summary PDF and you can add it in your chit Sheet. 88. Section 06 Cleaning & Organising History: Welcome to the last section of the ultimate it course. In this section, we will see how we can clean and organize the aids in gait. So we will see do commits, reward kids, recover lost commits, dropping commits, changing command message, splitting, squashing, and much, much more. In simple words, we will rewrite or git commit history. So let's start this section. 89. Rewriting the Commit History: Now the question you might ask why we need to rewrite our history. The reason we write the history or store the history of our project is we want to see how our application evolve with time. By history, we can see at that year, what are the features we launch, what are the bugs we fix, and who contributed to which feature, and many more things. Now imagine at the time when we see our history, we see bad commit message. Sometimes we commit small changes, which can done in single commits or we did really big amides in which we implement two features together, which is not good. Sometimes we might want to delete unwanted commits, then at that time, we have to rewrite our commit history. That's why this section is useful for making our history clean and organized, which is the sign of professional developer. Now you might ask, should we rewrite commits history of projects which are remote? The answer is no. We should not rewrite commits which we push to remote because that will mess up our project for others and we end up with big problem. In many companies, only the higher authority will rewrite the history. But first, he or she bring meeting or inform all team members about rewriting the history. But as developer, we can rewrite the commits history, which are local and not push to the remote. Rewriting the history, we can make our history more clean and organized. In the next lesson, we will start with do the commit history. 90. Undo the Commit in Details (RESET): So first of all, for this section, I designed one it project called Course cartwis. You will get the project in the resources folder which you downloaded at the beginning of this course. So you can open that folder in the Git Bash or in the terminal. Let's see the history of this project. See, here we have list of Commits. Here, we want to undo the amid. We already seen that in the previous sections, but I just want to make sure we don't miss any topic. So as we know for undo the amid, we use git reset command, and this reset has three options, LSD soft, LSDs mix, which is the default and hard. Let me explain to you each option one by one. So imagine this is our working directory code and we want to store that code in our Git history. First, we stage our changes, and then we do Commit. Now, after some time, we work on fixed one bug in layout design. We again stage the changes and commit it. Now here we want to undo the Commit B and we want to go back to commit A. If we write git reset the soft head till one, then Git will undo the commit in git history. Here, we get commit A, but it will not touch our working directory code and staging area code. They will stay the same as before. You know this current situation is which condition? When we do changes in the working directory and stage our changes, but we don't commit it. Now suppose at the place of there's the soft, we write mixed, then it will undo our last current commit to the head till one, which is a commit in the commit history. Also it will replace our staging area code with Com A code. But still, it will not touch working directory code. Do we know this condition is which condition? Right. When we do changes in the working directory, but don't stage that changes, you are really doing great. Now, if we write dash hard, then it will undo all area in head till one, which is one come before head commit, which is A. Do you know this condition? Right. When we just do Commit A, all our code is in the previous state. Let's see these options in action. Let's say we want to undo our last commit to the previous commit. First, let's see what we did in this commit. Get show Commit reference, which is head. See here in this commit, we change style dot CSS file. And here we add these lines of code. So first, we write git reset, da di soft. Here, we write our Comite has or pointer on which we want to move. So he, which is the current Camttll one, which is one commit before this amet. Know this will only undo commit in commit history and do not touch our working directory and also don't touch staging area. So our staging area has those lines, but our amit is reset to the previous version. So we can see that by see the difference between staging area and commit. For that, we have command, Git df das cast. See, here we get those lines. Now, let's write git reset, dd mixed, add till one. Command will undo the current command to the head till one command and also unstate the changes. Here, from this command, if we remove this test as mixed, then by default, get used test as mixed. We can check this by seeing the difference between working area and staging area. We can use Git status, or also we can use GTF. See, here we get this difference. Now let's see the last option, which is get reset, there's this hard head till one. Now our all a code will reset to this head till one. Now if we see the DF see, here we don't get any difference because all area is reset to head till one comet. So here our last three commits are gone because we run reset command three times. That's how we can undo the commit to a specific commit. 91. Reverting the Commits: In the previous lesson, we see how we can undo the coat. Now let's see reverting amides. Imagine we have two amides in our history, which we pushed to the github. Now we can't undo those amides and push it again. It will match the code for all our team members. So in this situation, we use revert, which means we can undo those changes which done by our omit B and create a new Kamed. Revert means back to previous version, but without wrapping previous amides. See this practically. So here we have our commit history, and I want to undo the changes which done by this third comet. Imaginary, we think this all come is pushed to the remote, so we can't use git reset. So we use here, Git reword and here we write Commit reference, which commit changes we want to undo, which is this Camt head till two. If we write head till one, then it will undo the changes done by the second Cate. Here, we can also revert multiple commits with one comet. If you want to revert all changes which done by this specific range of comets, so we can write something like this. First, we write the commit reference, one commit below, which is he till four. Double dot, here we write last commit, which is head. Remember, whatever commit we write first, it will take commits after that coat to the last commit. This command will revert the changes done by these four commits and create new four mets. Now, Git ask for Commit message for each new reward amide. I don't want to change the commit message, so I'm simply closing this each file and done. Now let's check our history. See, here we get four reward Camts. Now, as we can see reverting multiple amides is making our history messy. Is there any other solution which can clean this mess? Yes, there is one break. Instead of creating these four reward comets individually, we can revert those changes and put it into single met. So first, let's remove these four meds. We don't want them. Here, we can use reset because these four amides are not posed to the remote repository. So we will use gate resets hard and where we want to move our head. Right, we want to move here. So he, this is head till one, head till two, till three till four. So head till four. Now let's check our history. See, here we undo those four ametes. Now let's again revert these four comets, but we will create only one gamete. We write Git, revert, dn, das amet and here we write our Kameit reference same as before. Head till four double dot head. See here we don't get anything, but we can see we are in the reverting process. Currently, git revert all changes which happened in those four commands and put that changes in the staging area. We can check that using git status S. S, here we get three files with D, which is deleted and one with modified and also tamp which is untracked. We revert the changes in staging area. If you want to watch the changes or do some more changes, then we can do here. Currently, we don't want to do anything, so we can write Get revert. Here we have two options. About for aborting the revert, or we can continue the revert, which will lead us to commit that revert in single ait. We do continue Get ask for commit message. Here we have only last revert commit message. We can write here, revert last for Coit for tasting. Save this file and close it. Back to terminal, see revert is done. And in the history, we also get only one reword at. Now, as you can see, our three files are gone. So for now, we again reset this at because I just want to show you the demo of revert, but we might need these Camtes in the future. So get reset, there's this hard head till one and done. Now in the next lesson, we will see p log. 92. Reflog for recover lost commits : Now imagine in our code, we bi mystically reset our code to head till three. Here we can check our comet history. See, we lost our first three mets. Now, what if we want to recover those amets? Now, here you might say we lost that at. How can we get it back? In git, we don't really lose anything. Get store them in the repository and when those lost comets stay away for a long time, only Git removes that comets. If we bimstaally reset our code, then Git will not immediately remove those comets. Here we run Git Rf log, which is the full form of reference log. This command will show the reference of our default head pointer. Basically, it will show us how our head pointer moves in our history. Oh, what do we just see? Do you feel so much confusion? I'm just kidding. This is really simple. Let me explain to you that. This is just showing how our head pointer moves. At the first, we get commit a, then we get unit identifier for that point, and then we get the description of that action. At the very beginning, I did ten gametes straight in line. With each gamete, our head move. After that, in first lesson, we run this git reset command three times. Then we did four times revert and then reset, Camt and reset. Now, the good thing about this is we get all comets here. And in this lesson, we also did reset by mistake Lee. So we just need to move our head pointer to this previous reference and we recovered the lost comet. So git reset, D hard. Here we write our rough log reference or we can say this commit ID, or we can also use this commit ID. Head at in calibrakets. Now, if we check our commit history, see, we get our lost Cumms. What we learn from this When we run git reset command, Git don't actually remove those comets. Get just move Headpointer and put those commits somewhere in the history. If for a long time we don't touch those commands, then only Git will remove those commands. That's how we recover our lost comads using f log. Now, the one question many students ask me is, can we only see the headpointer reference log or we can see any pointers reference log you are right with Git flog command, we can see any pointers reference log. Currently, we don't have any branch. I will show you the f log of this master pointer. Git flog show, and here we write our pointer name, which is master. We have branch called feature cart, then we write here feature s cart. See here we get reference log for Master pointer. It is the same as head pointer because they move together in this history. Now currently, we see all reference or we can see full history. What if we want to see just last five moments of our master pointer? We can simply write here N space. Here we write five. See, here we only get last five moments of our master pointer. This is very useful, that's all about ref log. Now in the next lesson, we will see how can we do changes in the existing comi. 93. Amend the recent Commit: Now let's see amend command. So amend means correction. We can do correction in our recent command without creating new command. Let me show you. So here in the index dot ML file, we simply change the title to Cartwig Modern Ecommerce store. Save the changes less is these changes and commit this change with commit message, updating the application title. Now here we done our Commit, and in our title, I find we need to capital this W in Cardi spelling and also want to add hyphen between E and commerce. Here we don't want to create a new Camt for this tiny little change. Here we can use amend command. We make changes in our title, save this file, and let's teach these changes. For Gamat we write Gate KamitF amend we just add amend there's. Here we write our new commit message. Also, if you want to use the same commit message as previous commit message, then we don't write here anything. See, here we get the previous commit message. Close this and done. We update our last kommt. If we want to check what we have changed in our last Commit, then we can write Git show. See, here we get updated title. Now, one thing I want to clear is get don't really update the last Commit. Officially creates a new command because Git commits are immutable, which means if we create one commit, then Git cannot modify it. But here it shows like it is amending the last commit. Now, what if we want to add file in the previous commit? For that, we have to do the same process which we just did. Here in our project, we create a new file, scrape dot js and inside it simply console dot log. This is script file. Save this file and back to Git pas here we stage our changes and simply we can use Git commit, dd amend. Let's don't change the commit message. Now, let's check our last commit. Now as we add a new file in our last commit, how can we remove file? It's little tricky. So for that, first we use it reset, and here we use DDs mixed option because we just want to reset our commit history, and also we reset from stage our working directory will stay the same as before, teaching area and commit will reset. So get reset as does mixed, Head till one. C, we unstage changes, and in index dot STML file, we get our title. So we can delete this temp file and now we can stage our changes. And then instead of using Git commit, amend, we use simple commit because we reset our last commit and also give it a message, updating the application title and create script file and done. So that's how amend command works. Now, what if we want to amend any of these commits, and we will see that in the next lesson? 94. Amend any Commit in History: So in the previous lesson, we see how to amend our last comet. But what if we want to amend any previous at? Let's say these at styles for index STML body. In this amid, we want to change our body background color. So how can we do that? It's really simple. First, let's check what we change in that coat. So Git show d35, CB 01. See, here we can see we add style for body, but I want to change this background color. Here we are going to use rebase command. Let me explain to you what base command do. Imagine here we have six commits A to F, and we want to change commit, let's say C. We have to rebase to commit B because commit C base is commit B. So here we do changes in our commit C, and as we know, Git commits are immutable. Git can't change the commit. Git create a new commit which has our changes and then rebase it with commit B. You might ask, how can Git replace C commit with commit C? And what about commit D, E, and F? The answer is Git don't replace the commit C with C. Instead of replacing commit C, here, Git create commit, same as this commit D, but that commit has also the change which we do in CdS. If Git removes that change in the next commit, then what is the point of this? So that's why Git Pi exact same commit as commit D, but with changes. Same goes for commit E and commit F. Git remove this previous branch, and that's how by using git rebase, we can amend any commit in our history. But make sure we only change those commits which are not pushed because rebase clearly rewrite the history. Now let's see rebasing in action. So here, which commit we want to change. Write this one. So we copy the commit ID of its base, which is its previous commit. Always remember for rebase, we have to take previous commit reference. Now for rebase, we write git rebase I for interactive. Basically, we want to tell Git. We want to interact or make changes in our commits. And here we write our base commit, which is 4239 CEC. See here in our code editor, we get this type of interface. For now, we don't use this interface because it will confuse you. We will see how to use this interface in upcoming lessons. Here, from the bottom, we have switched to text option. Here we get these type of lines. Don't worry. These are just script which git is going to run, and these are all meds from our old to latest commit order. Here at the beginning of each amet, we have PC option, which means Git simply pick those comets from the history and rebase it. Now, what if we want to change this amet? So at the bottom of the file, we get many options and it's explanation. So for edit at the place of peak we write edit. Now we don't want to edit other amides, but if we want to do, then we can also write here, edit, save this file, enclose both files. See, here we stop at this Camt for edit, and currently we are in rebasing one of five, and we can see we can amend this commit now. So now we can change what we want to change in this coat. So in style dot CSS file, I want to change background color to white. And color to has 101010. Save the changes, and let's taste these changes. And also Gt ka mate, dash, dash, amend. Sorry, it is typo. So gate coat, dash, dash, amend. We continue with the omit message. So close this. Now at this stage, let's see the history. See, as I told you, Git start a new branch, and this is our base at. And here at the top, we get our updated amend Camt. Now when we continue this rebase, then Git pick these amides and put it on this Camt and then remove these old amete. Now to continue this rebasing, we write git rebase, continue. Or if we want to about, then we can write about. For now, let's continue this rebase and we don't have any other dits, Git quickly complete this process. Now let's check our history. Here we can see our history is again linear. If you observe, you realize all comets ID are different than previous comets. So it's confirmed Git creates new comets. But as we know, this is for organizing history. Now if we see in our code, then we also get those changes in our style dot CSS file. The changes we amend in that Camt is also available throughout these amides. That's how we amend any Camd by using git rebase I. 95. How to drop whole Commit: Dropping a whole at is useful when we bi mistakally commit our work. But when we drop any camet, we have to keep in mind we are rejecting all the changes we made in that comet. In our history, we have this work in progress at, which I bimstakally did. Let's see what I commit in this at gait, show AC a 49c. Here we can see in the index dot ML file. Instead of this text, we add this he tag, and in style CSS file, we add this style for section. Now, if we drop this command, then these changes will go. So for dropping also, we will use rebase. In our previous example, we have six commits, and if we want to drop this commit C, then we use gate rebase I, and here we start with base which is Commit B. And then we drop this commit C. Here, again, create a new commit for commit D, E, and F and then replace them with Commit B, that's simple dropping. Now, what if in this commit C, we create one file called page DML. In any three of these commits, we change something in that file. Then we get here conflict because when we drop Commit C, then our pg ML file will also drop. And in our other commits, we are making changes in this page dot S DML file. Then here we get conflict. Don't worry, we will solve it as it is using Merge tool. It is also very simple. I'm just telling you conflict can happen if we drop our commit. In our example, here we have these changes. Let's drop this commit and let's see we get conflict or not. What do you think? Let's see. So first, we write git rebase I and here we write our previous commit ID, which is our base. Again, here we go to the switch to text and here we get these scripts. Now we want to drop this coat at the place of this peak, we write drop or we can remove this whole at from script, save the changes, close these files and see here we get successfully rebase if we check our history, then see that working progress kate is gone because we don't get conflict. Let me show you what should we do if we get conflict because that might confuse you and I don't want you to get confused. Here in our project in components folder, we create a new file called myders dot HTML. In this file, simply add here H one tag, and this is my Order page. The changes and let's these these changes. Also, get create my order dot DML page. Good. Now, again, we change something in this file. So in ST tag, let's say this is the list of orders. Save the genes, and let's also stage this and commit it as well with Commit message updates for Orders page. Now let's see our history. Let's say we want to drop this second commit. So we do git rebase I and commit ID of our base, which is 9981 e53. Make sure you write your commit ID. Here we again get scripts in our code editor. We want to drop this commit, so we can remove this commit from here. Save this file, and let's also close this file. In the Git Bash, see, here we get conflict because we drop our commit and in that command, we are discarding all changes, which is we created Moder dot HTML file. We removed my order dot SDMLFle and in the very next commit, we are doing changes in that same file. So that's why we get conflict. Most of the time, we don't face this situation. But if sometimes it occur, then we can do like this. We can check our status by using Git status as a, C, here we get D and U, which means deletion and update. So to solve these, we simply write here git merge tool. See, here we get deleted merge conflict for components slash Moder dot stML Local is deleted and remote, which is indicating other commits. In those we have modification. So for modified, we can write A, for delete, we write D, and for Abort, we can write A. Here we don't want to delete our file. We go for Modify because we want to keep this Moder page in our Cmd. Now if we check again our status, then here we get added and we get this Moder dot stMl dot ORIG, which is the temporary file Gate create during conflict. We can ignore that or we can also delete it from our project. Now let's continue our rebase process using rebased Continue. Let's go with the same message and done. Now, if we check our history again, see our amid drops successfully. So that's how we drop our amid. Now in the next lesson, we will see how we can only change Commit message. 96. Changing Commit Message: Now in our current history, suppose I want to change the commit message of this second commit because the message is not clear. What do you mean by changes in index strategy ML, which change. And this type of commit message can create a lot of confusion. So it's always better to change these messages, so our history looks meaningful. First, let me see what I actually did in that commit. I really forgot that. Get show D six, a 7d59. Okay, here I add this product list section. So for changing the commit message, we also use here rebase. Get rebase I, and here we write our base commit ID, which is 61a8 71. Just keep in mind, base commit is always one coming ahead of Commit which we want to rebase. Again, we get here script. Now for changing the commit message at the place of peak, we write reward. Here we can also reword multiple commands. Suppose this last command we want to reword. We write here reword. Now when we close this file, it will ask us for the updated commit message for which commands we add reword. Let me show you save these close these files. See, I ask for commit message for our first command. Here we write adding product list section in index dot DML file. Save this and close this file. And again, we can write commit message for our last commit for which we at reward. I'm happy with this message. So let's go for it and done. Now if we check our history, see, here we get updated commit message. Now here, I again want to tell you, as we do repays, again create this Camt and as this commit is recreated, the all coats will recreate. So it's very clear we are rewriting the history. It is okay if we have gametes in our local repository, but we should not change gametes which are already pushed on remote repository. 97. Change Positions of Commits: Now, in our history, if we want to move commits up and down, let's say, here we have this updating the application title and create script file Commit. We want to move this commit below this ad class name in index dot SDMLKit. So here we again start rebasing get rebasi here we write base comet name where we want to put our gamete. Suppose here we have ten comets, we want to move the six comet after third met. In this situation, we start rebasing process from comet two because that will going to be base. Now suppose if we want to place the six comet after eight camet, then we start rebasing from the six comet. For changing the repository position, we always start rebasing from the lowest point. That's why here we start rebasing from this position. Nine E four, CD three D. So our rebase script has these all kats. Now here, we can simply move lines in which order, we want to reorder repository. So we go to the updating title and script file Cat and simply by holding Alt or Option, up and down arrow, we can change the position of the coats in the history, move it to the top of the history and save this file and cross these files. See, here we get successful rebase. Let's check our history. See this at move to the bottom, so that's how we can change the position of our amets. Now in the next lesson, we will see how can we merge two or more ametes in single amet? 98. Squash two or more Commits: Now let's see how we can combine two or three comets. So here in our history, we can see adding class name in index dot SML file and adding styles for index dotlFle body. These both codes can combine into single comet because that is the same process. So we will combine them together. Here, we again start rebase process from here. So get rebase I six F EA three F eight. Again, we switch to the text. Now we want to combine this second commit into our first commit. So for second commit at the place of peak, we write squash. If we also want to combine this third commit into this both, then we can also write here squash. For now, we don't want that, so we again back to peek. Save this file, and close these files. Now Git will ask us for the new commit message. Here we get all commit message, which commits we squash. So here, I'm choosing this first commit message and remove the second message. And also, we can change this commit message to add styles for index dot stML. Save this file and close. See here our rebase completed successfully. Let's see our history. See, we only get one coamte in our Comte history. Now suppose we bumstakely combine these coats. What if we want to undo last rebase? So here we use Gid Raf log. Here we can see at the top, we have rebase finish. After that, we have peak, peak, peak, squash, and rebase start. So we have to move to this Camt where we finish our previous rebase. Copy this Cait ID, and let's move to the bottom. And here we write Git, resets hard to this Cam. Let's check our history. See here we get again, those two separate kamts. Now the reason we undo this squash is because there is another way to combine our amides. We again write, get base I, our base amet here we get rebase script. Now at the place of writing squash, we can write Fix up. Now you might ask, what is the difference between squash and fix up? So they are almost same. But as we know, when we use squash, after that, we get chance to write commit message for that combined commit. But when we use Fix up, then we don't get the chance to write commit message. Get pick the first commit message as the combined commit message. Here, our first commit of combined repository is this. So it will pick this commit message. Save this and close the file. See, automatically kit complete rebase process without asking for commit message, and we get that message in our history. Now in the next lesson, we'll see how we can split single commit into two or more commits. 99. Splitting Commits: Now let's see the last topic of rewriting the commit history, which is by splitting big ametes into small camets. Here in this Camt we create CAT page and also user profile page. This can be big Kummet. We can split this single Camt into two comets, one for CAT page and another for user profile page. Here, our base Camt is also one comet ahead of this at. Let me show you another way to write previous amid. Here, we select our current commit and we copy its ID. Now, we write, git rebase I pass that current commit ID, and forgetting previous commit, we use here carat sign. This means this commit. Here we switch to the text. Now, this amit we want to split. So here we write, edit at the place of peak. So when we close this file, it will stay at this commit, and then by using reset command, we can separate our ammts. Let me show you practically. Save this file and close it. See we are in rebasing process. Let's see where we are exactly in our history. Git log, see, currently we are at this Camt because our head is here. Now what we want to do is we will use reset command for removing our current comite code from the staging area and also from our amet. Here, we write git reset, soft, but that will only remove our code from at. Want to remove the code from our staging area also. For that, we write here, is mixed. Now we are resetting the current commit code to which commit code. We will reset to the previous comet. Head, garret. Now in our working directory, we have all changes which we have done in that big amid, but they are not stage or not in cat. Let me clarify that with Git status. See, here we get two untracked files. So here we can do as many commits as we want. First, let's commit for cart page. So we stage first cart page file, Git add components slash cart dot sGML. We commit to change. Git commit, implement cart feature. Now let's check our history. See, here we get diverse history because our base is this and here our previous coamts. Now let's create another commit for user profile. We stage here components slash user profile dot SGML, and also CommitateGt commit. Now the reason we don't use here amend commit because we don't want to change in our current commit. Here we want to create a new Cat. So git dM, Implement User Profile feature. Now let's check our history. See at the top, we get two separate comets. Don't worry we are still in the rebase process. This is not the final output. Now when we continue our repase process, then Git will recreate these other comets and put it on the top of these two comemets by that, we gat linear history. Git rebase continue. Good, we successfully rebase. Let's verify that by history. See here we get two separate commits and our big commit is gone from our history. To quick recap, first we start rebase process, then we use it command in rebase script. After that, when we are at that big commit, we remove our current code from the staging area and commit area using git reset, mixed head carat. Head carat means we reset our staging area and commit code to previous Commit code. Here, we can stage changes and commit them, Commit one, and also again stage the changes, and then commit, which can be Commit two. And then we can continue Bs process and complete it so that S split Commit and rewrite our history. 100. Rewriting history using GitKraken: Now let's see how we can rewrite our history using Git Kraken. Here I duplicate the project which I give you for practice at the beginning of this section and simply open that in gate Kraken. Here we have all bad meds and we want to perform rewrite history. Now rewrite history is super easy in gate cracker and it is the same process in VS code also. Now rewriting history means we have to rebase. Here we want to start rebase process as the base of this at. So we write click on that commit and simply select here interactive rebase from this commit. In simple words, which commit we select, it will set as base kommt. Now here we simply get this type of rebase script. We already seen this interface in Vas code. Here, from this drop down, we can change the command. See for first commit I select reword. Here we can change our commit message. At the place of changes in index dot SDML, we write add product list in index dot SGML file and update the message. Now we also want to merge this third command into this second command, we can select here squash and see by using arrow, we get clear squash. Now here we want to also drop this work in progress coat. If we get conflts, then Git kraken, ask for modification, deletion, and also abort. Same as Gitask in our Git Bash. Let's start the rebase see, here we get conflict and we can see conflicted files at the right side. Click on that and here we take changes from B and simply do C. C, conflict is gone, and now we can continue this rebase or we can also abort that. Let's go for Continue and see all changes are done. That's a simple base in Git Kraken and viscode. But here is one thing. I Git Kraken or in Vs code, we can do amend commit or split comets. For that, we have to use terminal. That's why I first show you Git using command line and then for GI tools. Now, officially we covered all topics in gait. What do you think? What do you like the most about Git? Using it in terminal or using it with UI tools. I like to use Command line for all commands and GI tools for watching history and rebase. Your choice might look different, but it's your personal choice. At the end of the day, you have to work on your system. Whatever we use, our work should be done. 101. Section 07 Most Used Git Commands: Welcome to the recap section of the ultimate Git course. In this section, we will see all commands which are most common in developers life. It's like a revising git concepts. So hold some water and enjoy this section. 102. Git Basics & History Commands: I let's start with Git basic commands. First of all, for initializing our project, we use Gain init command. Or if we have already project on Cloud, then we use Git clone, and URL. After getting our project, we can do changes in our code, and then we can stage those changes using Git add. And here we write our file name. Staging the changes means these changes are ready for coat. It's like waiting area. Now, if you want to stage all the changes, then we write here Git add period. So if you want to see our current status, then we write Git status or git status for short status. Now, after we satisfy with our changes, we commit to changes to store that code in our gate history, to store that code in our gate history using Git commit, and we add here message. Here, make sure you write meaningful message. If we don't add any new file, then we can use this shortcut command, Git commit AM message. By this command, we can stage and commit our code in single command. Now, if you want to see difference between working area code and staging area code, then we can use Git DF if we want to see difference between staging area code and committed code, then we can use Git dif, stage, or we can use Git Di dash dash cast. After that, if we want to see our commit history, then we can use Git log command. And if we want to see history in one line, then we can use Git log, dash one line. We can also add other options like and graph for graph history. After that, if we want to see what we change in Commit, then we can use Git, show, and commit ID. Also, we can use her head pointer and if we want to see specific file, then we can use Git, show, commit reference and with column, we write our file path. So sometimes we want to switch code from one commit to another. Then we can use Git checkout, commit ID, or we can also use Git, switch, commit ID. Now, if in our project, someone write very bad code, and for checking the author of each line, we can use Git, blame and here we write our file path which we want to blame. If we want to see particular lines, then we can add here option L, and here we write starting line comma ending line number. After that, another most used command for marking Git commits is git tag, tag name. Then we write our commit ID for which we want to create this tag. If we want to remove the tag, then we use Git tag, D, and here we write our tag name and for C, the list of tags, we simply use Git tag command. These are the important commands related to Git basics and for watching the commit history. 103. Branch & Merge Commands: Now, let's recap about branches. When you want to work on separate feature or simply want to work on your team, then you should create a new branch and work on that branch. If we want to see the list of all branches, then we have git branch command. And for creating a new branch, we use Git branch and branch name. After creating new branch, we need to switch to that branch, and we can do that using Git switch branch name. Now if we want to create a new branch and also want to switch in single command, then we write Git switch, C, and branch name. Now to see what are the difference between a particular branch and our current branch, then we can write Git Div branch name. Also, we can see the difference between two branch using Git, D branch one, dot dot branch two. Now if we are working on branch one and suddenly we have to work on branch two, the instead of committing half code, we can stass that code. Stairs is like, keep that code in one corner, then we can switch to another branch and complete our or after that, we can apply the stairs in our previous branch. For creating the stairs, we use Git stairs, push, and here we add Ss message to see all stairs, we use Git stats list. Now, if we want to apply changes from stairs in our working directory, then we can use Git, apply, and stats ID. After apply changes from that stairs, we can drop that stairs using git stash, drop, and stats ID. And if we want to remove all stays from project, then we can use Git clear. Now, after that, if we done with our branch, then we can merge it with our main branch. And for that, we can switch to main branch, and then we can merge it by using git merge branch name. If we have diverge history, then Git will do three way merging, and if we have linear history, then Git will do pass for our merge. After we merge our branch in main branch, we can drop that branch using Git branch, D, branch name. If we want to forcefully drop that branch, then we can use Git branch, D, branch name. Also, we can reset the Kamed to the older version using git reset. In reset, we have three variations. Git reset, dash dash soft, Kate, which reset code from coat, git reset, dads mixed, which reset code from a and from Camt. If we use Git reset ds hard, then our all area code reset with that comite code. Now we can also revert the amid and the difference between reset and amid is with revert, Git create a new met, but in reset, Git don't create a new amid. Will do changes in the current Camt. For revert, we use Git revert and if we want to revert to parent one, which is the previous comet of our current branch, then we write here one and after that, we write Comte, which we want to revert, which is head. At last, if you want to copy one Comite code into our current Camt without merging, then we can use Git cherry peak commit reference. This is the overview of branching and merging. 104. Working in Team Commands: Now let's recap about working in team. First of all, when we are working in team, most command we use is git fetch, which is used to fetch changes of all branches from our cloud repository. After that, if we specifically want to fetch changes of only one branch, then we can write git fetch. Here we write our remote name origin, which is the most used remote and branch name. If we want to fetch from master, then we can write git fetch origin master or we can write git fetch only. This will work same. Now, as we know, by using fetch command, we will only get changes in our history. Our working directory stay the same as before. If we directly want to apply those changes from remote, then at the place of git fetch, we use git pull. But keep in mind, it will create a new commit. Now if we are done with our changes and we want to push the changes to the cloud. We have to write git push origin, master or main, whatever our project has. Also, we can use here shortcut command, which is Git push. Now we can also push our tag to the remote by using git push, origin, and tag name for removing the tag from origin, we use git push origin, dash delete, tag name. Now if we create a new branch and we want to push that branch to origin, then we have to first create upstream branch. We write git push origin branch name. After that, if we again want to push changes on this branch, then we can use simple gate push. Git will push the changes to that branch, that's all about working in team. 105. Thank you so much: So congratulations. You just completed the ultimate Git and Github course. And I just want to ask you, did you learn the git? Was I able to explain concepts that will help you to understand Git? I truly hope so. And in this video, I just want to say, thank you so much for watching this complete it and Github course. I am really, really grateful for that. And please, if you want to share your review about this course, then at the top, you can see bating button, and by that, you can share your review. Whatever you want to say, positive or negative is really important for me. Giving this feedback will take no more than 10 seconds, but that will give me inspiration and motivation for creating more better courses, and it will also help me to reach more students who wants to learn Git and Github like you. Thank you so much for watching this course and all the best in your developer's journey, and I hope your all dreams becomes true.