Start learning with our library of video tutorials taught by experts. Get started
Viewed by members. in countries. members currently watching.
The course shows how to use Git, the popular open-source version control software, to manage changes to source code and text files. Using a step-by-step approach, author Kevin Skoglund presents the commands that enable efficient code management and reveals the fundamental concepts behind version control systems and the Git architecture. Discover how to track changes to files in a repository, review previous edits, and compare versions of a file; create branches to test new ideas without altering the main project; and merge those changes into the project if they work out. The course begins by demonstrating version control in a single-user, standalone context, before exploring how remote repositories allow users to collaborate on projects effectively.
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.
Find answers to the most frequently asked questions about Git Essential Training.
Here are the FAQs that matched your search "":
Sorry, there are no matches for your search ""—to search again, type in another word or phrase and click search.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.