So, you're starting to get more comfortable with this idea of Git branching. But what about when you encounter a merge conflict? How does that work? Let me show you what I mean. I once again have that Laravel project installed. I will git init. Since we're starting from scratch, I will git add everything to the staging area and git commit with the message of install Laravel. Now let's check out a branch. So git checkout -b and why don't we call this feature/ and then something that represents

Now let's check out a branch. So git checkout -b and why don't we call this feature/ and then something that represents what you're working on. It doesn't really matter in our case. So we'll open this up in Sublime. And then if I visit maybe the welcome page and we scroll down, we'll get to work on this. We'll say maybe welcome to Laravel 5. We'll do a number of things and we will commit our work. git status. Yep.

or a hotfix branch that gets merged into your master. So how exactly do things work when you modify a particular piece of code on one branch but also another branch? Well, when we merge those, how is Git supposed to know which modified code you want to keep? This is called a merge conflict. Let's see this in action. I'm going to check out the master branch. And once again, I will open up Sublime, visit the welcome page, and this time we're going to change this bit of code or whatever is relevant in a slightly different way. This time, maybe we'll do something like this.

to change this bit of code or whatever is relevant in a slightly different way. This time, maybe we'll do something like this. We'll add an extra space and we'll say this is Laravel 5. Slightly different, right? Okay. So I will git status, looks good. git add and git commit with tweak homepage copy. All right. So let's check this out. First, I'm going to do git branch.

So let's check this out. First, I'm going to do git branch. And when you leave it just like this, it'll show you each branch that you currently have set up. Of course, in our case, we have two and this one is green with a star because it's the currently active branch. You can also do git branch -v and this will show you the most recent commit per branch. So here we can see, yep, both branches have a commit that changed the same lines of code. So when we merge this, once again, which set of code takes precedence? Let's see.

So when we merge this, once again, which set of code takes precedence? Let's see. I will git merge that feature. Uh-oh, automatic merge failed. So remember, last time around, it was an automatic merge. There were no conflicts there. But this time, there were. We've already established that there would be. So how do we go about fixing the conflicts? I'll show you.

So how do we go about fixing the conflicts? I'll show you. git status and here we can see, yep, we haven't committed anything just yet like we did before. No commit. So when we run git status, we can see where the merge conflict occurred. Because remember, if you're committing 10 files, very possibly none of those files could be merged automatically. But one file has a conflict and you need to fix that before you can commit everything. Now if I were to copy this and run git diff, we could see the difference. Or if I were to open up the file itself, we can view it there.

So it's up to you now to let git know which one wins. In our case, why don't we say this one wins. Okay, just delete everything to make it work. That's how I want this to look. And if I now run git status, here's the modified file. I can add it. And now we've staged it and it's ready to commit. So I just type git commit. You'll see the message here. Remember, last time, this happened automatically.

You'll see the message here. Remember, last time, this happened automatically. But this time, there was a conflict. So we took a second, fixed the conflict, and now we're once again committing. And I can close this out. Done. git log. And you've now resolved your first merge conflict.