Join Kevin Skoglund for an in-depth discussion in this video Fetching changes from a remote repository, part of Git Essential Training.
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.
- Exploring the history of version control
- Installing Git on Mac, Windows, and Linux
- Initializing a repository
- Writing useful commit messages
- Understanding the Git three-tree architecture
- Tracking when files are added, edited, deleted, or moved
- Viewing change sets and comparing versions
- Undoing changes and rolling back to previous versions
- Ignoring changes to select files
- Creating and working with code branches
- Merging branches and resolving merge conflicts
- Stashing changes for later
- Working with hosted repositories and remote branches
- Developing an effective collaboration workflow
Skill Level Beginner
Q: In the Chapter 10 movie "Configuring the command prompt to show the branch," when I type the function "__git_ps1," I do not get the expected result.
A: The function "__git_ps1" was recently moved to a new file, .git-prompt.sh, as described here: https://github.com/git/git/commit/af31a456b4cd38f2630ed8e556e23954f806a3cc.
We will update the video. In the meantime, you may do the same steps you do for .git-completion.bash, but a second time using ".git-prompt.sh" as shown here: https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh.
Q: When I use the code the instructor advises in the above video ("git config --global user.name "Nelda Street"), I still get an "Illegal Instruction" error. I have OS 10.6.8. Am I doing something wrong?
A: The current installer version of git isn't compatible with older Mac OS versions.
1. To add "-mmacosx-version-min=10.6" as described here:https://stackoverflow.com/questions/14268887/what-is-the-illegal-instruction-4-error-and-why-does-mmacosx-version-min-10https://stackoverflow.com/questions/10177038/illegal-instruction-4-shows-up-in-os-x-lion
2. Or to use the version of git that comes with Xcode, or to use homebrew to install git instead.http://superuser.com/questions/697144/installed-git-not-sure-how-to-get-it-working