Okay, I mentioned earlier that getting everything up-to-date would
require merging the local and remote branches.
How does this work in practice?
As it turns out, when you have a remote set-up,
Git stores local copies of all the remote branches.
These will each contain the state of the remote branch as of the last time you
pushed or pulled the branch.
Let's look at how this would play out over the lifetime of a repository.
We'll consider a repository that got created on GitHub with a readme, and
then got cloned.
Remember that cloning sets up a remote for you called origin.
We've already seen that when you clone a repository, you get a local branch
called master, that points to the same commit as the remote one.
But what you haven't seen yet is that you also get a local copy of
the last known position of that branch on the remote.
The name of that branch includes the name of the remote, origin,
since you can have multiple remotes set up,
as well as the name of the branch on the remote.
In this case, master, which is to be separated by a slash.
So in this case, it'll be origin/master.
And since we've just had an interaction with the remote,
it's currently in the same location as the actual remote version.
Let's consider what happens when you
make commit on the master branch locally.
As usual, when you make a commit on a branch,
that branch will get updated to point to the new commit.
But, neither the local origin/master branch, nor
the actual master branch on the GitHub repository,
will get updated because you haven't communicated that you want to do that.
However, if you push the master branch, the local origin/master branch and
the remote GitHub branch will get updated with the new commit.
Similarly, if this branch were to get updated on GitHub and
then we pulled, both of these would get updated with the new commit.
Let's go back to thinking about what happens if you've got different
changes on each repository, with one change locally and another remote.
It turns out that you can update just the local copy of the remote branch,
leaving your actual local version alone by running the command git fetch.
In cases like this, where there are potentially conflicting changes,
using git fetch to update the local copy of the remote branch can be nice,
so that you can use git log and git diff to see what changes were introduced,
both on the local and remote repositories.
This way, if you're going to be offline for
a while, say if you're about to get on a plane,
you can update your local copy of the remote branch before you leave.
And then you'll have access to any updates that have been made to
the remote since you last synced up, while you were offline.
But you don't have to act on combining those commits right away.
Speaking of combining changes,
now that you have the commit from GitHub on your local repository, it's now
possible to incorporate them into your master branch, using git merge.
It turns out that this is exactly what happens when you do a git pull.
First, the remote branch gets fetched,
updating the local copy of the remote branch.
Then, that branch gets merged into the local one.
To put it more concretely, in this case,
fetching updates origin/master with the contents of GitHub's master branch, and
then origin/master is merged into master.
So git pull is the same as git fetch followed by git merge.
Now Caroline will demonstrate doing this process on the recipes repository on
the command line.
>> I can update the local copies by running git fetch origin, which will
update all of the local copies of every branch for the origin remote.
I can inspect the local copies by running git log origin/master.
Or git diff origin/master master.
But before I do that,
I want you to predict what you'll see if you run these commands.
You can also run the commands yourself to see if you're right, but
it can help to think about this before trying it.
I'd like you to predict the output of git log and
git status both before and after you run git fetch.
If you run git log origin/master before you run git fetch,
which of these commits do you think will be shown?
Larry's commit, adding the chili recipe?
Your commit, adding a new spice?
Sarah's commit, removing cumin?
Check all that apply.
Similarly, check all the commits you think will be shown after you
run git fetch.
When you run git status on the master branch,
Git will let you know whether your local master contains any commits that are not
reachable from origin/master or vice versa.
If you run git status before you run git fetch,
will it say that your local master is one commit ahead of origin/master?
One commit behind origin/master?
Will it say that your branch is up-to-date,
meaning the two branches point to the same commit?
Or will it say the two branches are out of sync,
meaning each has a commit not present in the other?
Similarly, after you run git fetch, what will git status say?