Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
In the last movie, we used git fetch in order to sync up origin/master with the master branch on the remote repository, but we noticed that while it brought those commits down into origin/master, it didn't bring them into master on our local repository. All it did was get origin/master in sync. If we want those changes to be incorporated into our master branch, we need to do that additional step ourselves, and that's we are going to learn how to do in this movie, using merges. Now you will recall earlier that I told you that origin/master is just a branch like any other branch.
It's a remote branch, the only thing that really differentiates it from the branches that we normally work with is the fact that we can't check it out, other than that it's really the same, and it make sense that we can't check it out, because Git really needs to be able to keep it in sync with what's on the remote server, and it doesn't want us getting in the way of that. If we check that out, we might make a commit to it, and that would just confuse things. Instead, we have our branches that we are in charge of, but Git is going to remain in charge of origin/master and make sure that it mirrors what's on the remote. But other than the fact that we can't check it out, it is exactly like any other branch.
That's an important point to remember, because we are going to merge with it just like any other branch. In this illustration, you can see that the remote server has five commits in it, and a fetch has taken place, because origin/master is perfectly in sync with what's on the remote server. Our master branch however is two commits behind, so it needs to have those two commits added to it, and the process that we do that is by merging, and the merging works exactly like everything that we learned about merging before in the merging chapter. The only difference is that we are using a branch called origin/master, instead of some other branch name that we worked with before.
But in this particular illustration, if we were to do a merge right now, master would do a fast-forward merge just like the fast forward merges that we learned about previously. Now if we made additional commits on the master branch, in the meantime, then those would need to be merged in, and we would have a merge commit that would join those together just like we did before. And of course, it's also possible that the 923ea commit that's in origin/master has something that conflicts with what we have got in ba8ce in our master branch, and if it conflicts, well just like with the normal merge, we have got to resolve those conflicts.
And we resolve those conflicts in the exact same way, and we commit the result into our merge commit. Let's try it out. Okay, notice that I am inside my lynda_ version folder, and I am on the master branch. First, let's just remind ourselves where our branches are, we have git branch, and we will use the -a option so that we see all of them. So what I want to do is I want to take master and merge it with origin/master. We can also just do a diff if we want first to find out what's the difference, master origin/master, and it tells us, so we can see what those changes are.
Okay, now that I know it's different, yes, I do want to go through with that merge. So git merge and just like before, normally we would type a branch name, now we are going to type origin, and then the branch name. So merge in origin/master, so I will hit Return, and you can see sure enough it tells us right here that it was a fast-forward merge, and now get log --oneline, we'll do three lines for the master branch, and you see that now the change has appeared there. Now let's just look at the diagram again and just make sure that something is super clear you, when we do a merge, we are merging with origin/master.
Our local version, that's where we are merging in, we are not going back up to GitHub to see what's there. So when we do a merge, we always want to make sure we do a fetch first. Fetch, then merge. Now it's possible that new things might have come in, in the meantime of the remote server, we will worry about those later, but we do want to do our best to be as up-to-date as possible. So now that we understand this process, git fetch, git merge. That's the process that we are going to go through. I want you to know about a shortcut called git pull. Git pull is equal to git fetch+git merge.
It does it all in one step. It goes out there, finds the latest, brings it down and merges it into your current branch, all in one big shortcut. Now there are lots of pros and corns to using git pull. First, it's super convenient. So a lot of people use it by default for that reason. The bad part is, that for beginners, it obscures the fact that you are actually doing this two step process, and I think that a lot of people who use git pull a lot, forget about doing git fetch and git merge. They don't really realize that that's what's it doing for them under the hood, and then sometimes when things go wrong with git pull, it's hard for them to understand what actually went wrong and what happened and how to fix it.
If you use git fetch+git merge, it's much harder for those kinds of problems to arise, because it's much clear what went wrong and how to fix it. So my recommendation is to try and use git fetch and git merge for a while, until you feel like you've got the hang of it and then if you know that what you really want is just git fetch and pull down the changes, then you can try using git pull.
Get unlimited access to all courses for just $25/month.Become a member