Git Branching and Merging - Detailed Tutorial

In this tutorial we're going to learn the three skills that will get us to a professional level of git. And these skills are branching, merging, and the feature branch workflow. In order to follow along you'll need to know the basics of git and github. I go over that in part one and two of this tutorial, but you don't need to watch them, these are optional. You just need to know the basics of git and github to follow along with part three. So here's a situation that will come up when you're working professionally on a team, that you usually don't run into when you're working alone. Let's say that you're working on a feature and this is a pretty big feature so you decide to split up your feature into multiple commits. So you write some code, then you create a commit, so that it's saved in your version history in case you mess up. You write some more code, then you create another commit, and one day your manager comes to you and they say: hey, we actually have a bug in our website, and we need you to fix this bug. So what do you do? You don't actually want to fix this bug and then put it in your version history, because your version history contains the two commits that you made that are sort of work in progress, you're not really sure if they work, you're not really done your feature. So git has a solution for us, which is branching. So in branching we're going to create another branch of commits, that will branch off a master, so think of this as like a tree branch. master is sort of the trunk and then you have a branch coming out of the trunk. And the great thing about creating a branch like this is that if you have a bug fix, you can put that bug fix directly on your main branch and you can continue working on your feature that you're working on until you're done. So that's how git solves this problem of working on multiple things at the same time. For this part of the tutorial we're actually going to start fresh. We're going to create a new git repository, and a new version history to practice with, just so that it's easier for us to see what's going on. Let's go into our computer, and we're going to create a new folder that's going to contain all of our code. I'm going to call this folder git tutorial 3. Feel free to call it whatever you want. Now I'm going to open this folder in my code editor, file, open. I'm going to find this folder on my desktop. We're going to create a version history with three commits in it. Feel free to pause the video if you want to try that out yourself for practice, otherwise we're going to do it together. We're going to open our command line, and remember that the command line has to be running inside the folder that contains our code, which is this folder. So first we have to change directory to tilde slash desktop slash git tutorial 3 and now we're going to initialize git so that it's going to start tracking all of our changes. git init As a reminder there is a cheat sheet of all the git commands that i teach in this tutorial so that you don't have to write notes while you're watching, and you can find that cheat sheet in the description below. And now we're going to add some changes, and then add that to our version history. So we're going to keep this really simple, we're going to create a new file let's just call it hello, and we're going to call this version 1. Very simple. And to create a new version in our version history, remember we're going to do git add dot. So git add picks which changes we want in our version but it doesn't actually create a version, and dot is a special character that represents the current folder which is this folder. So we're going to commit, create a commit and let's just say this is version 1. And now let's keep going and create three versions in our version history. So let's create version two, again, git add dot git commit dash m version two. And then finally version three git add dot, git commit dash m version three. Okay, and now let's check our work by running git log dash all dash graph. And you can see that we have a version history, with three versions or three commits of our code. Now let's look at the situation that we described earlier, which is, let's say that we want to work on a new feature, and this is a pretty big feature so we're creating some commits along the way. But then our manager comes and asks us to add a bug fix for the website. The way to solve this problem is to use a feature of git called branching. You can think of branching as you're sort of creating a copy of your version history, but then you can add commits to the copy instead of your main version history that you had before. And the advantage of this is that you can add all the commits that you want to the copy while you're working on the feature, before your feature is done, and while you're still working on your feature you

can add bug fixes to your original version history. This lets you create bug fixes and lets you put the bug fixes on your real website, without having your new feature and your work in progress code getting in the way. Let's see how we do this using git commands. So the first thing we need to do is we need to create a new branch, so remember a branch is sort of like creating a new copy of your version history that you can work on the side. To do that, the git command for creating a branch is git branch and then we're going to give this branch a name. Usually you would name your branch based on what you're working on. Let's say that you're working on social login, so you would name your branch social login. But for our example, let's just keep it really simple, we're just going to call this branch feature one. And now to check our work, we're going to run git log dash all dash graph to see our history. And now you can see that we essentially have two branches over here. So we have the master branch, yours can be called the main branch. So this was our original version history and now we sort of have a copy of our version history, and this copy is called the feature one branch. So now what we want to do is we want to put our commits for a new feature onto our new branch instead of our main branch, because this main branch is usually used as the final copy of your code for the website. So you generally don't want to put in progress, or work in progress code onto your main branch, so how do we switch to working on the feature one branch. The git command for switching to a different branch is git checkout, and then the branch that we want to switch to. So we're going to switch to feature one. Now let's run git log dash all dash graph to check our work. If we look at our version history, we can see that we have this word HEAD, and it's pointing to feature one, so head basically tells us that we are currently working on the feature one branch, any commits that we create are going to be added to the feature one branch. Notice before, that head was pointing to master, and we were working on master before. And then we used git checkout to switch to the feature one branch. So now let's go ahead and add the code for our feature. We're going to make this really simple, we're just going to create a new file called feature, and let's say that this is the first commit for our feature. So our feature is really big, we're going to split it up into several commits. And now let's go back into our command line, and create a new commit for our feature. Let's call this feature commit one, and let's check our work by running git log dash all dash graph, and now you can see that we have our master branch that we had before, but now we're working on our feature one branch. So this essentially separates our new work in progress code, from our original version history. Now let's get some more practice, we're going to create another commit for our feature pause the video if you want to do it yourself for practice, otherwise we're going to do it together. Let's go back in here, I'm going to create commit 2 for our feature, the commit now so git add dot, git commit dash m feature commit two, and now let's check our work again with git log dash all dash graph. Now you can see that our feature 1 branch now has two additional commits. And our master branch is still the same. So this is how we work on something without disrupting our original code. Now let's say that our manager comes to us, and they say that they need a bug fix for our website. Let's say that this bug fix is a relatively simple fix, so we're just going to create the fix, we're going to test the fix, and then we're going to add it to master. And then master is going to go up to our real website, and it's going to fix the bug. So how do we do that? Well the first thing you have to realize is that we're currently working on feature one, so remember the head tells us which branch we're working on, and right now it's pointing to feature one so we essentially want to go back to master, and then start adding commits to master. So how do we switch back to our master branch? So let's quit out of this view by pressing q if you need to. And the command for switching branches, remember, is git checkout and the branch name. So we're going to switch back to our master branch, and let's just run git log dash all dash graph to see that it worked. So now you can see that head is now pointing to master, which is what we want

and you can also see that our code has gone back to the master branch and this new file that we created in our feature branch has been deleted. Now let's create our bug fix. We're just going to really simplify this, we're going to create a new file, and we're going to call it bug fix, and let's just pretend this is our bug fix. And now we want to put this fix into our master branch. So let's go back into our command line, and because we are working on the master branch, we just have to create a commit. Let's press q if you need to. git add dot, git commit m bug fix. Now that we created the commit, let's check our work with git log dash all dash graph. Now you can see that there's actually a branching effect that's happening in our history, so we have our feature 1 branch, which contains our new feature and it contains our work in progress code, and we also have a bug fix in our original branch. So by using the branching feature of git, it allows us to work on multiple things at the same time, whether that is a feature and a bug fix, or two features at the same time, or even more than two features and a bug fix at the same time. So that is an introduction to branching, and how we use branching and what kind of problems it solves. You can see that we're using branching to work on multiple features at the same time, but now we also have another problem. Here, we eventually want to combine all of our changes together, so let's say that we're working on a feature in a separate branch just like this. We don't really want this feature to be in this separate branch forever right? we eventually want to put this feature, as well as a bug fix, all into our code. So how do we do that? Well git provides us another tool that helps us combine all of these separate branches. And this tool is called merging. So don't worry, merging is actually pretty easy to understand, I'm gonna give you a pop quiz here to show you what I mean. Let's say that we have two branches. On the first branch, we have a new file with this content, and on the second branch we have another new file with this content. Now we're gonna merge the two branches together, and I want you to let me know what is going to be the result of this merge. So feel free to pause the video if you need to think for a bit, otherwise I'm going to show you the answer now. For this question is actually pretty simple. The result of the merge is that we're going to have both of these new files now let's try another question. This one's a little bit more tricky let's say that we have one branch where we changed this line in the file, and then we have another branch where we changed another line of the file. What's going to be the result of this merge? Feel free to pause the video if you need to. The answer to this question is also pretty simple, the result of the merge is that in this file we're going to contain the change from branch 1, and we're going to have the change from branch 2. So this file is going to contain both the changes, from both the branches. And that's the result of the merge. So as you can see merging is actually pretty intuitive to understand you're just taking changes from one branch, and changes from another branch, and you're just combining the changes together. That's what merging is. So basically in git, we're gonna do this process, but git automates this for us so instead of us going through each file of the code and figuring out what's changed, and combining all of the changes, git is just automating this process for us. It's actually pretty intuitive once you get the hang of it. So let's go back into our code, and let's say that for the feature we're working on we're going to finish up this feature by adding the third and final commit. So the first thing we need to do is right now we're working on the master branch let's go back to working on our feature branch. We're going to press q to quit if you need. To I'm going to run git checkout feature 1 to switch to this branch and let's run git log dash all dash graph to check our work. And now we're working on our feature one branch again, so now let's finish up this feature. So as we said I'm just going to make it really simple, let's say that we're going to create commit 3 and this is the end of our feature. feature done. And now let's run log dash all dash graph just to see what's going on. So now you can see that we have finished our feature, and our master branch is over here with the bug fix, and now we essentially want to combine all of them together. We want to merge this branch with this

branch, so that we have all of our changes. So one question you might have is: where does the result of the merge go? Does it go on top of the feature one branch, or massive branch? Or does it go somewhere else entirely? So the answer to this question is that when you merge two branches together, the results will go on to the branch that you're currently working on. So remember we're currently working on the feature one branch, that's where HEAD is pointing to. So if we merge feature one and master together, then the result of that is going to be another commit on top of feature one. The next question we have is where should we put our merge result? Should the merge result go on top of the feature one branch or should it go on top of the master branch? So there's really nothing that enforces you to put the merge results on either branch, so git doesn't really have any rules here, but generally within a company if you're working on a team, they like to use the main branch or the master branch as sort of a final copy of the code that's eventually going to go to the website. So that's why we want to put all of our changes, we want to merge all of our changes back into the master branch. This is sort of the final copy of our code. So let's learn how we can merge everything we have in feature one back to master. So the way to do this is that, press q to quit, we are going to first switch to the master branch, and we're going to merge feature one into master. Let's take a look at how we do this. Let's switch to master first by using git checkout master, remember your branch can be called main, and now let's again always check our work git log dash all dash graph. Now we're on the master branch. Now we want to merge feature one into our master branch, and to do that we just have to give this command, git merge feature 1. So the way that git merge works is that you're going to give it a branch name and it's going to merge that branch into your current branch. So right now head is on master so we're working on master and this is going to merge feature 1 into master, and then it's going to put a new commit on top of master with the merged result. So remember the merged result is basically you're taking all the changes from the branch and another branch and you're just combining all the changes together. There's not really much magic going on, but git automates this process for us. So one other thing that I forgot to mention here is that when we merge these two branches together, the result is going to be saved in a commit, so that commit has to have a message, and it's a little easier for us to write the message here. So we're going to do dash m and we're going to give a message. So usually you don't really need the dash m, you can just run git merge feature one, but this might require you to have a little bit of knowledge about vim or emacs or whatever editor you're using in your command line. I'm gonna assume that you don't have that knowledge so we're just gonna do it the easy way, which is giving the message here. So let's just give a very simple message, which is merge feature one and now we're going to press enter to run this merge. And now we can check our work by running git log again so git log dash all dash graph and now we can clearly see that the new branch we created has been merged into our master branch here. So our master branch contains both our bug fix from down here as well as the feature that we were working on in this branch. So we essentially combined all of those changes together, and now the final copy of our code has both our new feature, and our bug fix. So we learned how to use branching to work on multiple things at the same time and now we learned how to merge all of our work back together into the same code. Now we're going to learn about merge conflicts, which is when git doesn't know what the result of the merge should be so this is actually also pretty straightforward to understand. I'm going to give you another pop quiz to show you what I mean. Let's say that we have two branches again, and we want to merge these two branches together. In the first branch we have a file changed and this is the change, and in the second branch we have the same file changed, and here is our second change. So now what is the result of this merge? And the answer here is, we don't know. In this situation it's not clear whether

we should take the change from branch one or if two. You might think that the combined result of the merge result should be that we have both of these changes, but the problem here is that the author of branch one wanted to do one thing, the author of branch two also wanted to do one thing, and if the code, and the combined code does two things, then it's obviously not the right answer. None of the authors wanted to do two things. So essentially we have to pick between branch one or branch two, we don't know what the answer is, and neither does git. So that's what a merge conflict is. It's when git tries to merge these two changes togethe, r and it just doesn't know which change we should take, and it just asks us which change that we want. So let's take a look at a merge conflict in practice. To create a merge conflict to practice with, we're going to create two branches and on each of the branches we're going to change the same file on the same line. So let's go ahead and do that in git right now. So first let's create another branch. So remember git branch creates a branch and this is the branch name, now let's check git log. You can see we have two branches master and conflict. So now let's switch over to the conflict branch, git checkout conflict and let's change one of our files. Let's change the feature file, and we're going to change this to conflict one, just to keep it simple. And now we're going to save this change into our version history, so we're just going to create a commit conflict 1, and as always we're going to check our code or check our work with git log. And now we can see that our new conflict branch has our commit, so now let's go back to our master branch and change the same file in the same line. Let's go back to git checkout master and now we're back on the master branch. You can see that the code is also back to the master branch, and we're going to change this to conflict 2. And now we're going to add another commit so we're going to change, we're going to save this change into our version history, on the master branch conflict two. And now finally let's check our work one last time git log dash all dash graph. And now you can see that we have this branching going on. On the master branch we changed this line of code, and on our conflict branch we changed the same line of code. So if we were to merge these two branches together, we will get a merge conflict because it's not really clear which change we should take, or which change from which branch we should take. So now let's demonstrate that by running git merge, and remember when you run git merge we're essentially taking another branch and merging it into our current branch. So right now our current branch is master, and you can tell that by the HEAD and the arrow. So we're going to merge conflict into master, and we're going to save the result on master. So that's what we're going to do here. And let's just give a commit message just to keep things simple, so merge conflict and press enter to run that. And now you can see that git is telling us that we have a merge conflict, which is basically what we did in the exercise before. Remember that we didn't know which line of code we should take, git in this situation also doesn't know which line of code we should take, and that's just what it's telling us. So now if we go back into our code, you can see that git added a lot of stuff here, so what does this mean? So basically git is saying that: hey, these are the lines that I'm confused about. So this is the version on the current branch so if we go back to our log, so remember that we were working on master so head is pointing to master. So over here this is saying that on the master branch this, is the code that we have. And on the conflict branch which is the other branch that we had this is the code that we have. And git is saying I don't know which line you want, and you got to tell me which line that you want. So git is basically saying that here are the two lines of code that I'm confused about, and you as a developer have to decide which one you want. And to tell git what we want the final code should be, we just have to

have the final code, and then delete everything else. So let's say that we want the final code to be this line, we just have to delete everything else, so we're going to delete all this stuff, and that's going to be our final code. Now on the other hand, let's say that instead of this line from the master branch, we actually want this line from our conflict branch to be the final code. We just have to leave this line in place, and delete everything else. So that's pretty simple we just have to tell git what the final code should be. And one interesting thing about this is that if we go back to what we had before, You actually don't need to pick one of these lines, you can actually just delete everything, and write something entirely different. And git doesn't really care, it just wants you to tell it what the final line of code should be. So I can write anything that I want and git doesn't care, it'll just take whatever I wrote and put it in the version history. So for this example, let's just keep it simple and we're just going to go back to what we had before, and we're going to pick one of these branches to be our final code, so let's say that we want this branch to be our final code. We just delete everything else, and keep that line. So just to summarize, to resolve a conflict, you just tell git what the final code should be, and you delete everything else. And now we can finish the merge by going back into our command line, and to finish the merge, we just have to create a new commit. So we're going to git add dot I'm going to create a commit merge conflict resolved, and now if we run git log to check our work, so now you can see that we have successfully merged our branch into master, even though there was a merge conflict. So to summarize, a merge conflict is when git doesn't know which change to take, and it just tells us hey I don't know which change to take, here's the change from branch one two, now you as a developer, you have to tell me which change you want. So we go in, we tell git what the final code should be, and then we create a commit to finish the merge. So that's how you merge and that's how you resolve merge conflicts. The last skill we're going to learn is called feature branches. So this is going to take everything that we learned in this tutorial and it's going to combine it all together into a sort of process of how we should use git and github. Once we learn feature branches we're going to be at that professional level of git, which means we're going to be good enough to work at a company as a professional engineer in terms of our git skills. So just as a reference, every team that I've worked on has used feature branches. Now what are feature branches? So feature branch is something that we call a workflow, it's a step-by-step process that we follow when we're using git and github, and we just need to learn what this process is, and how to follow this process, so let's get started. We'll start with an overview of the steps in the feature branch workflow, and then we're going to learn how to follow these steps by doing a hands-on example. So we actually know a little bit about feature branches already. When we first learned about branching, we said that branches allow us to work on two different things at the same time. So when we create a new feature, we create a branch for that feature first, and then we put all of our commits for that feature on the new branch. So we typically call this new branch a feature branch, and that's where we get the name of the workflow from. So there's one other problem that we haven't solved here, and that problem is code reviews. Basically when you're working on a new feature, before that feature goes into your website, you need another software engineer to look at your code. It's helpful for them to spot maybe mistakes that you made, or if there are any bugs in your code. So how do we use git and github to do code reviews? This is part of the feature branch workflow, that's going to solve this problem. So we already learned the first part of the workflow, which is creating a branch for our feature. We call this the feature branch. And the next thing we're going to do is we're going to upload this branch to github. Remember that github is our remote repository, it not only contains a copy of our code it also version history. This means that we can also upload part of our version history on our computer to github. So after uploading our branch to github, our remote repository is going to look like this. It's going to have our master branch, and a new branch that contains our feature. The reason that we're uploading it to github is that now all the other engineers on our team can see our code, and that's going to help us do code reviews. So once our branch is on github, there's a process on github that allows

us to do code reviews. It allows us to do tests on our feature branch if we need to, and then once all of those pass, we can merge our feature branch into master, and that's going to go into our real website. So in the previous section you'll notice that we merged two branches on our computer, this time we're going to merge the branches on github. So that's how we're going to manage our merges. Let's take a look at a specific example of the feature branch workflow. We're going to go through it step by step. So let's pretend that we're making a new feature, we're going to keep this really simple, we're just going to create a new file called new feature. And just make this really simple. Now remember that we want this feature to be on a feature branch. So the first thing that we're going to do before we create a commit, is we're going to create our feature branch. So let's create a branch here using git branch and let's just call this new feature, and let's run git log dash all graph to check that it worked. So now we have both a master branch and a new feature branch, but notice that we're still working on master. So instead, we want to be working on our new feature branch. To do that remember we can do git checkout and the branch that we want to switch to. And let's run git log just in case. And now we can see that we are now working on the new feature branch. So the last thing we have to do is to add our commit to the feature branch, so git add dot, git commit dash m new feature. Now to push this branch up to github, first we need a github repository so let's go into our github account. We're going to create a new repository that we can upload to. So we're going to go in here and we're going to click your repositories, new. And now to name this repository, I'm going to give it the same name as what I have on my computer so I'm going to call this git tutorial 3. I'll keep it as public and I'll click create repository. Now remember to upload to a github repository, we first have to add a link to our github repository. So we this repository in our local repository. So let's take the url of our github repository and add a link to it. So to do that we can use git remote add and we have to give a nickname to our remote repository, so let's call it origin, this is the most common name that people use. And we're going to paste the url to our github repository. Let's press enter, and now the first thing that we want to do is we actually want to upload our master branch first. If you're at work, usually the master branch would be the default branch, you usually have it on github already, but because we started off our git repository on our computer, we actually don't have a default master branch here. So the first thing we're going to do is we're going to switch to our master branch, and we're going to upload that to github and then we're going to switch back to our new feature branch and upload our feature branch to github just so that it's consistent, with what you would have if you're working at a real company. So to switch to our master branch we're going to git checkout master and remember the git command to push this to github is git push and we're going to push to origin which is this github repository and we're going to push the branch, which is master. And now if we go back to github and we refresh, you'll see that we now have our git history uploaded to github, and we have the master branch. Now the second thing we're going to do is this is actually part of the feature branch workflow, is we're going to upload our feature branch to github. So to do that we're going to do git check out new feature, we're gonna switch to that branch first, and then we're going to upload it. So git push origin new feature. We're gonna push to origin which is github, and we're going to push our new feature branch. And now if we go back to github and we refresh the page. In this drop down you can see that we have both a master branch

and a new feature branch you might also see this message saying that it's giving you an option to create a pull request right now. That's exactly what we need to do to initiate a code review, but sometimes you might not see this option so we're going to create a pull request manually. To create a pull request you can either click this button, or we can go into this pull request tab and we're going to create a new pull request. So pull request basically takes your branch, your feature branch, it compares it to master and it initiates a code review. So it lets other people look at your code see what changed, and it lets them add comments just in case you have any bugs or mistakes in your code. So we're going to take a look at what that process looks like. We're going to create a new pull request and we're essentially going to be merging our new feature branch into master. So this is the same thing as merging except we're doing this on github this time. So you have to make sure that we have the right direction here, and the way to do that is to look at this arrow. So this arrow means that we're taking all of the code changes in our feature branch and we're going to put it back into master. So that's what we want because master is sort of the final copy of our code that's going to go on our website. So once we have this set, we can click create pull request, and we can write a description describing our changes if we want. I'll just give, I'll just give a pretty simple description here. This is a new feature. And finally we can click create pull request, and that initiates a code review. So what happens here is that you give this url to your teammates, and then they're gonna go open this pull request on github, they can go to this file changed tab and they can see all the changes that you made. If they don't like a change, they can say um bug and essentially they can start commenting on your code and telling you what they want to fix, or something that they want to improve. And now if you go back to our conversations tab, you can see all of the comments that the code reviewer has left, and once we resolved all of these comments, we're now ready to merge our feature into our main branch. So this is what we learned when we learned merging earlier, except we're going to do this in github. And to do that all we have to do is press this merge pull request button, confirm merge, and that's it. Because we've done a bunch of stuff on github, and we've merged the branches on github, we want to go back and sync those changes back to our local repository. So remember the command for doing that is git pull. So let's go back into our local repository, and let's actually see what happened on github. So the command to get all the updates from our remote repository is git fetch. And now let's check our git log to see what everything looks like. And this is a little bit hard to read so we're going to go through it step by step. So in our local repository on our computer, we have a master branch and we have a feature branch. So this hasn't changed the other thing that we did is that we uploaded this feature branch to github so now origin has a branch called new feature. So this is the result of uploading our local feature branch onto github. And you can also see that on github the master branch contains not only our local master branch, but also the result of the merge, so that's why origin slash master is ahead of our local master. In order to update our local master branch up to here, all we have to do is first switch to master, git checkout master, and now to pull changes from github we're going to run git pull. Actually we have to give the name of the remote repository to pull from, as well as the branch. So we're going to pull the master branch from origin, our github repository and press enter. And now we run git log dash all dash graph. You can see that our local master branch is now in sync

with what is on github. So that is the feature branch workflow. As you can see it's basically just a step-by-step process that you follow when you're using git and github and this is what allows companies to have a team of engineers working on a single code base. Now once you get the hang of the future branch workflow, this means that we are at a professional level of git because the majority of companies use this workflow in their projects. So we're going to look at an overview of a very common situation. So there are two engineers and they're both working on different features. So engineer one is going to create a feature branch called feature one, and engineer two creates two. Now in these branches let's say that they both change the same file and the same line, so this is going to create a merge conflict. So engineer one uploads their branch to github, engineer two also now engineer one is going to create the pull request, as we explained in the feature branch workflow. That's going to get reviewed and then they're going to merge their branch into master. There's not going to be a conflict here because master doesn't have any new changes so there are no merge conflicts. But now when engineer 2 tries to merge their branch into master there's going to be a merge conflict because there's a new change that changes the same file and the same line as their own branch, and that's going to result in a conflict. So this is where a merge conflict can occur in the feature branch workflow, so we're going to take a look at a hands-on example. So first let's try to simulate that situation, we're going to start off with our master branch and we're going to create a feature one branch and a feature two branch, and they're going to change the same file on the same line to create a merge conflict. So let's go ahead and do that so right now. We're already working on the master branch so what we're going to do is we're going to create two new branches, so let's start with feature one. Actually feature one already exists so what we can do is we're gonna delete that branch, using git branch dash capital d feature one, and we're going to recreate that branch. So essentially when we create a branch that new branch is going to be created wherever HEAD is. So right now HEAD is at master, we're going to create a new branch right beside master. So git checkout, we're going to run git log dash all dash graph, you can see that right beside master we have a new feature one branch. So according to our example we're going to change the same file in the same line. Let's go back into our code and pick one of the files, let's say this file, so we're going to change this to feature one and we're going to commit this change onto the feature one branch. So remember right now we're working on master, we want to switch to feature one, so git checkout feature one, and now let's add a commit. Now the second part of our scenario is that we have a another branch that changes the same file the same line, so let's create that right now. So if we run git log dash all dash graph again you'll see that head is now pointing to feature one. We actually want to start a new branch from master, so we have to switch to master first, and then create a feature two branch. So let's git check out master to switch to master, and then we're going to run git branch feature 2 to create our second feature branch. And now remember we have to switch to our second feature branch, and we have to change the same file and the same line. So let's take this file which is the same file as we changed in the other branch, I'm going to change this to feature two, and we're going to save that change in a commit. Now let's run git log all graph to check our work. So now you can see that we have our master branch here, and we sort of have a feature one branch and a feature two branch branching out and they both change the same file in the same line. Now what we're going to do is we're going to upload both of these to github, and we're going to create a merge conflict. First since we're already on feature 2

we can upload that to github so git push, we're gonna push to origin, and we're gonna push the feature two branch. Okay, once that's done let's go into github and make sure it worked. So let's click this link to our repository, and if we click this drop down here, we can see that we now successfully uploaded our feature two branch. Next we're going to upload our feature one branch so we first have to check out, and then we're going to push our feature one branch to origin, which is github. All right so let's refresh, and now you can see that we have both of our branches on github, we're ready to create pull requests, do code reviews and merge both of these. So let's start with feature one first, I'm going to go to the pull request tab and we're going to create a new pull request. This is going to request to merge feature 1 into and so we want master, be careful of the arrow. And now we're going to click create pull request, create pull request. And let's also create another pull request for feature two, So that this is something that happens a lot at work is when you have one pull request and you're working on a feature, and another engineer creates another pull request at the same time, and then the resulting merging creates a merge conflict. So let's actually create another pull request here for feature two so in this pull request we're going to merge all the changes from the feature two branch into master. We're gonna create. Great okay so now we have two branches that want to be merged into master, there are pull requests that are open people are reviewing their code, and let's say that feature one finishes code review first. So they merge their features into master first, we're going to click merge pull request to merge this. And now if we go back to the pull request for feature two, you'll notice that we now have a merge conflict. So the reason we have a merge conflict is remember that in our github repository, our master branch now has a new change, and our feature 2 branch also has a change, and these two changes basically modify the same file and the same line. git is not sure which line to pick. One of the trickier parts of this scenario is that the merge conflict is on github, so you can either use the web editor, which essentially does the same thing as we had in our local repository that we learned when we learned about merge conflicts. So once we decided what we want the final code should be, let's say that we want this to be the final code, we're going to delete everything else and we're going to click mark as resolved and after that we're going to click commit merge. So that will resolve the merge conflict and it will allow us to merge this feature 2 branch into master. We just learned how to resolve merge conflicts in the feature branch workflow, but notice how we use github's web editor to resolve these conflicts. Sometimes we actually want to resolve these conflicts on our own computer, because we can run the app we can use our code editor, basically we have more tools to help us with these conflicts. So in this section we're going to do exactly, that we're going to take these merge conflicts from the feature branch workflow, and we're going to bring them to our computer, and we're going to resolve them on our computer. But first we need to set up our git history in order to practice this scenario. We're going to set up the same scenario that we had before, first we need to go check out master and then run git pull origin master, just so that we have the latest updates from github. We're going to have two branches that modify the same file on the same line, and that's going to create a merge conflict, and then we're going to push both of these branches to github. So instead of naming these branches feature 1 and feature 2 like previously, let's name these feature 3 and feature 4. So I'll let you do that as an exercise and I'll see you back when you're ready.

I basically created the same scenario that we had before, except this time we're gonna call the branches feature three and feature four. First we're going to merge in feature three, which is going to create a merge conflict on feature four. Let's go back, open the feature four pull request, and now we can see that we have a merge conflict. So how do we resolve this on our local computer without using this web editor? So if we look back to the previous pull request, you can see that to resolve the merge conflict, we have to merge master into feature two. So this time we just have to merge master into feature 4, but we're going to do it on our computer. So I'm going to go to the command line, the first thing I have to do is I have to update my master branch so to do that I'm going to check out master, and I'm going to git pull any updates from github, which is origin back to my master branch. And now I'm going to git checkout feature four. So remember, as a reminder we're going to merge master into our feature branch. So remember that when we run git merge, we're essentially taking another branch and merging it into our current branch. So first we're gonna switch to the feature four branch, and we're gonna merge master into this branch. So now we're going to git merge master and now we can see that we are in the same scenario that we had before when we were first learning about merge conflicts. So let's go into our code and fix these conflicts. And you can see that git says I don't know which of these lines you want, for convenience here's the line from HEAD which is feature four and here's the line from the master branch, which is feature three. We can take this line, or we can take or we can write something completely different, git doesn't care it just wants us to tell it what the final code should be. So let's say that be feature four. So let's delete everything else and remember to resolve a conflict we're going to add it, and we're going to commit everything in the end. So let's go back to our command line. We're going to add the changes that we made, or the resolution that we made, and we're going to commit this change, and this will resolve the merge conflict. So git commit conflict resolved, and now we just merge master into future four. So we resolve the merge conflict, we have to push these results back up to github, so we're going to push origin feature four. We go back into github and go back to this pull request, you can see that we just resolved the pull request. Of course I gave the message of conflict resolved, but what we really did here was we took the master branch and merged it into our feature branch. So that is how you resolve merge conflicts in the feature branch workflow if you want to do that on your computer and how you do that on the github web editor. And that is the end of this tutorial, we went from zero experience in part one to a professional level of git and github in part 3. I do realize that I did leave out some skills such as git rebase. I actually did record them but I didn't feel like I did a really good job explaining them. However this tutorial is meant to give you just a foundational overview of git and github and how we use these tools in a professional workflow. So I'm going to leave that up to you now that you have this foundation, it's a lot easier to learn these other git skills incrementally. Thank you so much for watching my name is Simon from supersimple. dev I want to make a tech career possible for anyone. If you have any questions or comments please leave them down in the comments, as always you can contact me at super simple. dev feedback I'll see you in the next one