Master: git pull

---

In this video we'll break down git pull as well as learn how to use the --rebase option.

In init: git pull, we used git pull to bring a branch up-to-date with its remote counterpart.

In addition, I mentioned git pull is a shorthand for git fetch and git merge.

Let's demonstrate this by again resetting our master branch back a commits.

Now instead of running git pull as we did in the init video, let's run git fetch.

There's no output, so everything is up-to-date. Which makes sense as we recently ran git fetch and nothing has changed.

Now let's run:

git merge origin/master

We see from the output Git fast forwarded our branch with the recent changes.

We can verify this by running git log --oneline --decorate --graph --all.

Notice we passed origin/master to git merge. We can prefix any branch with the remote name followed by / to reference its remote counterpart.

Since git pull is a shorthand it's therefore more common. Nonetheless, it's important to understand the component steps.

This way if running git pull doesn't behave as expected, for example by creating a merge commit, you'll know why.

So, now that you know why you may receiving a merge conflict, let's talk about how to handle it.

Again, I'll reset the master branch back a few commits.

However, this time, I'll make some changes and add a commit before running git pull.

This creates the scenario where I have local changes that have not been pushed to the remote and the remote has changes I have not pulled.

Let's try running:

git pull origin master

Git opens a text editor with a merge commit. This means the commit history of the local and remote branches did not match.

In this case, because I have new changes on an out of date branch.

So, to prevent the merge, I'll clear the commit message and save.

This dumps me back to the command line without completing the merge.

Now I can run git merge --abort to abort the merge which reset the state of the repository back to before I ran git pull.

We can verify this by running git status.

Also, notice in output from git status that Git has detected that our branch has diverged from origin/master. And the local branch contains 1 commit as well as the remote branch contains 1 commit.

What I want to do bring my branch up to date then add my new changes.

As we learned in Part 3 this is exactly what git rebase does.

git pull has a --rebase option. So instead of running git merge it runs git rebase.

Let's try again using the --rebase option by running:

git pull --rebase origin master

Similar to the output from git rebase, we see Git first brought our local master branch up-to-date, then re-applied our new commit.

So, we should now be one commit ahead of origin/master and we can verify this by running git log.

While --rebase is a helpful option for this scenario, it's best not make it a common practice.

If you follow the workflow covered in Part 3, you'll rarely need to use git pull --rebase.