In this movie we're going to learn how to fetch changes from a remote repository.
In the last movie we made some new changes in our explore_california repository, and
we pushed those changes up to GitHub,
but when we switched over to the Lynda repository to take a look at what Lynda would see, we
don't see those changes there; git log --oneline, let's just do -5.
Oops! --oneline needs an e in it, and you can see that it's not there, and it doesn't
matter if we're on master or if we ask it for origin/master.
Same thing, it doesn't exist in master, and it doesn't exist in origin/master.
Also let's notice that if we ask for git branch, we only have our master branch.
If we ask it for a list of the remote branches it comes up, and it just says that we have
master there as well.
Remember we pushed up another branch as well, we pushed up the non_tracking branch.
So there is both a new branch and a new commit on GitHub that Lynda can't see yet.
Why is that? Well, it's because Lynda needs to do a fetch.
Remember a fetch is what synchronizes origin/ master with whatever is on the remote repository.
Origin/master doesn't automatically reflect what's on the remote repository, we have to
tell Git that we want it to do a sync between the two.
When I did this line here where I looked at the log of origin/master, that doesn't actually
go out to GitHub to see what the log file is there.
It's looking at the local copy that Lynda has in a repository from the last time that
she synced up, the last time that she did a fetch, which was when she originally cloned
to this repository.
So this git log command can actually be done when we're away from a network connection.
We don't have to have access to GitHub to find out information about origin/master.
We won't get the latest information, we'll get the latest thing that we synced up the
last time that we downloaded it.
But when we do a git fetch, it does go out to GitHub and pulls down information, and
we do need to have an Internet connection in order to do that. So let's try that now.
The command is git fetch, and then we can provide the name of what we wanted to fetch,
we want it to go to origin, which in our case is GitHub, so git fetch origin, and bring everything back.
Because we only have one remote repository, we can just abbreviate it as git fetch.
So you don't have to type it all out, you can just simply say git fetch, and it will
know that you mean to fetch from the one and only remote repository that you have.
So let's try that now and see what happens.
So you can see it counted the objects we don't have, there's five of them, decompress them,
brought them down, and here they are.
This is the range of commit numbers.
You can see this f3a370e is the commit that we were looking for, that's the one that wasn't
there, and it found the new branch, right.
This new branch non_tracking, it brought non_tracking from the remote non_tracking into origin/non_tracking.
Now if I say git log --oneline -5 origin/master, now look at that, we see the change because
now we've done a sync.
Now origin/master is in sync with what is on the remote, so it has all the same commits
that are there, all those same git objects have been brought down to our machine.
And if we do git branch we can see we still only have one branch, the git branch -r now
knows about the non_tracking branch.
We downloaded information about that.
So whenever we do git fetch it's synchronizing with the remote repo, and that means it pulls
down any Git objects we don't have, and it pulls down bookmarks that reference the tips
of each of the branches that are on the remote.
Now if we look at the log for just master, not origin/master, but just our master branch,
you can see that that commit is still not there.
I didn't bring it all the way into our master branch, that's ours to manage, right? It just
brought it into the origin/master, which is going to try and always be a perfect sync
with what's on the remote repository.
It's just our local cached version of the remote repo.
So that's an important point, when we synchronize with remote repository using fetch, we just
update origin/master. Master doesn't change at all.
If we're in the middle of working on something, and we've got some edits in our working directory,
those aren't affected.
If we've made some commits over the last hour, those aren't affected.
It has nothing to do with any of our non-remote branches whatsoever.
A fetch is not harmful in any way at all, and because of that there is absolutely no
reason not to fetch often.
In fact, I want to give you three basic guidelines that you should try and follow.
The first is always fetch before you work.
The very first thing in the morning that you should do when you sit down at your computer is do a fetch.
Find out what's on the remote repository, what commits were made over a night by your collaborators.
Get those all down onto your computer, and then you can decide what to do with them from there.
The second is fetch before you push.
You've got your commits, you've made them, they're not on the remote repository, before
you push them up there find out what else is on the remote repository.
Maybe someone else already pushed the similar commit or maybe they pushed something that's
going to conflict with what you're about to push. Go ahead and get those changes downloaded
so that you know about them before you start putting new stuff on there.
And then the last one is just to fetch often.
It's not destructive, so there is no reason not to do it often, and you certainly want
to do it anytime you're about to leave a network connection.
If you're going to go take your laptop to work in the park or you're about to get on
an airplane, you want to do a fetch to make sure that your repository is in sync with
what's on the remote.
Now because it doesn't automatically bring those changes into our master branch, if we
want them there, then we're going to have to put them there ourselves by doing a merge,
and we'll do that next.