00:00:00 when two or more developers edit the same lines of code, Git gets confused.

00:00:06 This is called a merge conflict.

00:00:09 When this happens, Git will ask you to manually choose which or whose changes to keep.

00:00:16 But why don't the merge conflicts happen when you're working on your project alone?

00:00:20 A merge conflict is a situation where Git is uncertain about which part to merge.

00:00:26 But why would Git be unsure?

00:00:28 To show you what I mean in practice, let me create two branches.

00:00:32 First, I'll create a branch called the DevJSM.

00:00:35 So let me run git branch dev-jsm and press enter.

00:00:42 This will only create a branch, but not switch to it.

00:00:46 Now, let's immediately create and switch to another branch.

00:00:50 We can do that with a git checkout –b, and then the branch name command.

00:00:56 I'll call this one DevAdrian, and you can of course use your own name, and press Enter.

00:01:02 Now, I'll make some changes to the codebase from the DevAdrian branch.

00:01:06 Specifically, I'll go to ReadMe, and I'll change Hello Git to Welcome to Git.

00:01:14 I'll also add another line and say, this is coming from Dev Adrian, like this.

00:01:21 Now let's add the modified file to Git by using git add dot.

00:01:26 We can write a meaningful commit message by doing git commit-m.

00:01:31 And let's try to be descriptive of what we did.

00:01:34 It's always easier to track the changes that way.

00:01:36 So I'll say modify readme by changing the heading.

00:01:42 and adding a new line.

00:01:44 Press Enter, and at this point, everything is looking good.

00:01:48 But the branch is, of course, not yet visible on GitHub, since it only exists on our local system.

00:01:53 To publish the branch to the remote, run git push –u origin and then the name of the branch, dev-adrian.

00:02:02 and press Enter.

00:02:04 The U sets the branch as an upstream branch, and the origin, as you know, is the name of the remote repo.

00:02:10 If we go back to GitHub, you can see that DevAdrian has recent changes, so let's open up a pull request.

00:02:18 There we go, modify readme by changing the heading and adding a new line, and create a new pull request.

00:02:25 Great.

00:02:26 The pull request is there.

00:02:27 Now, for just a second, imagine you're not yourself.

00:02:30 You are your friend.

00:02:32 So let's actually move to your friend's branch by running git checkout, and we called it dev.jsm.

00:02:39 Remember, this branch was created off of the main branch at the time when other you didn't yet add those additional changes.

00:02:47 So let's say that your friend also wants to modify the readme.

00:02:52 Instead of saying, hello Git, they're going to say something like, hey yo, everyone.

00:02:57 Welcome to my Git guide.

00:03:00 And they'll add an additional line and say.

00:03:04 Yo, Johnny here, and they're going to commit their changes by running git add dot git commit dash M.

00:03:12 And of course they don't know how to write quality commit messages as you do.

00:03:16 So they're going to write something like today I woke up and drank some coffee.

00:03:23 Then I sat at the table and added a few lines of.

00:03:28 code.

00:03:29 Super long, but doesn't really tell us anything, right?

00:03:31 Of course, we have to push that branch by running git push dash u origin dev dash jsm or whatever name of the branch you chose.

00:03:41 And now our friend is going to come to GitHub and they'll want to open up their pull request.

00:03:46 So let's do that right away.

00:03:48 Their title is so descriptive, it doesn't even fit in one line.

00:03:52 And now we have two PRs currently opened.

00:03:55 And even though you opened up your PR first, life sometimes isn't fair.

00:03:59 So let's say that whoever is supposed to review this PR just didn't want to even see the code that this guy wrote, so they immediately merged it.

00:04:08 The key takeaway here is that they merged it before yours got merged.

00:04:13 That's great for them.

00:04:15 But now, if you go to your PR and try to merge it, you'll see something like this.

00:04:21 This branch has conflicts that must be resolved.

00:04:25 Merging is blocked.

00:04:27 Now, it is highly likely that whoever is reviewing this won't even start reviewing it until you resolve the conflicts.

00:04:33 So they'll most likely write something like, Adrian, please fix these merge conflicts.

00:04:39 So what just happened?

00:04:41 Why do you have a merge conflict?

00:04:43 And most importantly, how can you resolve it?

00:04:46 The merge conflict happened because both DevAdrian and DevJSM made changes to the same file.

00:04:54 specifically to the same line in the same readme.md file.

00:04:58 When the reviewer approved and merged the DevJSM branch, it created a new commit that made changes to the same line of code that DevAdrian has already modified.

00:05:09 Therefore, when you tried to merge your branch with the main branch, Git could not automatically resolve the conflict and required you to resolve it manually.

00:05:18 In other words, Git was just not sure which version of the code to merge, since two different versions existed on two different branches.

00:05:27 When Git encounters such a conflict, it expects you as the user to resolve the differences and decide which version to keep,

00:05:36 and then manually update the code to reflect the changes made in both branches.

00:05:41 This is a typical scenario that happens when both you and your teammate are working on the same code simultaneously, on the same code at the same time,

00:05:51 resulting in modifications to the same line of code and finally causing a merge conflict.

00:05:57 It is something that no matter how much you try to avoid it, always happens.

00:06:02 So you're likely to encounter those merge conflicts from time to time.

00:06:05 So how can you resolve them?

00:06:08 Well, there is a standard process that you need to follow.

00:06:11 With enough practice, it'll become second nature.

00:06:14 Here is what you have to do.

00:06:16 First, check out the main branch by running git checkout main.

00:06:21 Next, pull the latest changes from the remote main branch.

00:06:25 Or in other words, the changes that your friend got merged before you by running git pool.

00:06:31 There we go.

00:06:32 We can see his stupid comments right here.

00:06:34 Now your local main branch and remote main branch are identical.

00:06:38 So you can safely check out to your own branch.

00:06:42 git checkout dev adrian.

00:06:44 Stop here and let me ask you a question.

00:06:47 When you created a pull request, which branch were you attempting to merge the changes into?

00:06:52 Well, of course, the main branch.

00:06:54 So what are we trying to accomplish here?

00:06:56 If you're not sure, let me show it to you in action.

00:06:59 Run the command git merge main.

00:07:03 That's correct.

00:07:04 You have just merged the main branch into your branch.

00:07:08 Although the initial objective was opposite, it was to merge your branch into the main branch.

00:07:14 But that process didn't work due to the merge conflict.

00:07:18 So we first must resolve the issue.

00:07:21 And to do that, we're merging the main branch into our branch to identify the problem.

00:07:26 The command we just used, git merge and then the branch name, is used to merge that branch name that you specified right here,

00:07:34 such as main in our case, into the branch we're currently on.

00:07:38 And now that you run this command, you can see that there are merge conflicts in readme.md.

00:07:44 automatic merge failed, fix conflicts, and then commit the results.

00:07:48 Most code editors have some kind of a versioning system right here on the left sidebar.

00:07:54 By pressing command zero, I can open up WebStorms 1. Here, you'll be able to see a list of all merge conflicts.

00:08:02 In this case, we have only one, and it is in the readme.md file.

00:08:06 Let me show you how to read it.

00:08:07 Arrows pointing to the left side that say head refer to the changes coming from your branch.

00:08:14 and arrows pointing to the right side that say main refers to the changes coming from the main branch due to the merge command that you executed.

00:08:22 To resolve them, you can manually choose what you want to keep or remove by removing those lines and clearing up the code that you don't want there.

00:08:30 But the usual way is to click the resolve button.

00:08:34 On WebStorm, it looks like this, but the options should be similar across all code editors.

00:08:39 Typically you have three options.

00:08:40 You can choose whether you want to accept your code, whether you want to accept their code, or whether you want to do something in between.

00:08:48 Of course, wouldn't life be so simple if you could just choose one of those two options.

00:08:53 But typically, that's not what you want to do.

00:08:56 In most cases, you'll want to keep some of your code and some of their code.

00:09:00 So we'll have to go with the third option.

00:09:02 This interface will differ depending on the code editor you're using.

00:09:06 Sometimes it might be inline, so you see the red and green lines directly within a single file.

00:09:12 But I very much like the way in which WebStorm is doing this.

00:09:15 On the left side, we can see our changes.

00:09:18 On the right side, we can see their changes.

00:09:20 And in the middle, we can see the result.

00:09:23 So you can just choose which one you want to merge.

00:09:26 In this case, they wrote something that's not so useful, so we want to keep ours.

00:09:31 And now that gets transferred over to the middle one.

00:09:33 Welcome to Git.

00:09:35 But let's say that this code is an important implementation of some feature within their branch.

00:09:40 Of course, in this case, it's just the line of text, but I think you can imagine how Johnny can really write something useful.

00:09:47 So let's say that we also need to merge this.

00:09:50 And at the same time, we have also added an important feature from our own branch.

00:09:54 So we can add it right here as well.

00:09:56 So the final result will look something like this.

00:09:59 Modified heading, Johnny's feature, your feature, and then the feature that was previously there.

00:10:06 Let's remove this stop change from Johnny because we preferred ours better.

00:10:10 All changes have been finished and we can click Apply.

00:10:14 And there we go, here is our new readme file containing both Johnny's changes and our changes without conflicts.

00:10:23 Now let's open up the terminal, run git add dot to add our newly modified file, say git commit dash m, resolve merge conflicts,

00:10:34 and run git push.

00:10:37 You already know the drill, right?

00:10:38 Now return to GitHub and check the PR.

00:10:41 If you scroll down, you'll see that there is no more merge conflicts because they've been resolved by a resolve merge conflicts commit.

00:10:48 Now it would make sense to tag your reviewer and say something like merge conflicts resolved.

00:10:57 Please check.

00:10:59 Then they'll be able to go through a code base.

00:11:01 Request some changes if necessary.

00:11:04 And finally, merge your pull requests to the main branch.

00:11:07 Now, if you go back to the code, you can see that there's a new commit to the readme three minutes ago.

00:11:13 And our heading has now been cleaned up.

00:11:15 It doesn't include Johnny's nonsense anymore, but it does include their features.

00:11:20 It includes your features and it includes features previously added to main.

00:11:25 Amazing work.

00:11:27 Now you know how to resolve merge conflicts, one of the scariest things to do as a developer.

00:11:33 And I know it all looks intimidating at first, but with enough practice, it'll become second nature.

00:11:39 Trust me.