What is the difference between 'git pull' and 'git fetch'?
What are the differences between
git pull and
In the simplest terms,
git pull does a
git fetch followed by a
You can do a
git fetch at any time to update your remote-tracking branches under
This operation never changes any of your own local branches under
refs/heads, and is safe to do without changing your working copy. I have even heard of people running
git fetch periodically in a cron job in the background (although I wouldn't recommend doing this).
git pull is what you would do to bring a local branch up-to-date with its remote version, while also updating your other remote-tracking branches.
From the Git documentation for git pull:
In its default mode,
git pullis shorthand for
git fetchfollowed by
git merge FETCH_HEAD.
Read more... Read less...
When you use
pull, Git tries to automatically do your work for you. It is context sensitive, so Git will merge any pulled commits into the branch you are currently working in.
pullautomatically merges the commits without letting you review them first. If you don’t closely manage your branches, you may run into frequent conflicts.
fetch, Git gathers any commits from the target branch that do not exist in your current branch and stores them in your local repository. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repository up to date, but are working on something that might break if you update your files. To integrate the commits into your master branch, you use
It is important to contrast the design philosophy of git with the philosophy of a more traditional source control tool like SVN.
Subversion was designed and built with a client/server model. There is a single repository that is the server, and several clients can fetch code from the server, work on it, then commit it back to the server. The assumption is that the client can always contact the server when it needs to perform an operation.
Git was designed to support a more distributed model with no need for a central repository (though you can certainly use one if you like). Also git was designed so that the client and the "server" don't need to be online at the same time. Git was designed so that people on an unreliable link could exchange code via email, even. It is possible to work completely disconnected and burn a CD to exchange code via git.
In order to support this model git maintains a local repository with your code and also an additional local repository that mirrors the state of the remote repository. By keeping a copy of the remote repository locally, git can figure out the changes needed even when the remote repository is not reachable. Later when you need to send the changes to someone else, git can transfer them as a set of changes from a point in time known to the remote repository.
git fetchis the command that says "bring my local copy of the remote repository up to date."
git pullsays "bring the changes in the remote repository to where I keep my own code."
git pull does this by doing a
git fetch to bring the local copy of the remote repository up to date, and then merging the changes into your own code repository and possibly your working copy.
The take away is to keep in mind that there are often at least three copies of a project on your workstation. One copy is your own repository with your own commit history. The second copy is your working copy where you are editing and building. The third copy is your local "cached" copy of a remote repository.
If there is sufficient interest, I suppose I could update the image to add
git clone and
One use case of
git fetch is that the following will tell you any changes in the remote branch since your last pull... so you can check before doing an actual pull, which could change files in your current branch and working copy.
git fetch git diff ...origin
See: https://git-scm.com/docs/git-diff regarding double- and triple-dot syntax in the diff command
It cost me a little bit to understand what was the difference, but this is a simple explanation.
master in your localhost is a branch.
When you clone a repository you fetch the entire repository to you local host. This means that at that time you have an origin/master pointer to
HEAD and master pointing to the same
when you start working and do commits you advance the master pointer to
HEAD + your commits. But the origin/master pointer is still pointing to what it was when you cloned.
So the difference will be:
- If you do a
git fetchit will just fetch all the changes in the remote repository (GitHub) and move the origin/master pointer to
HEAD. Meanwhile your local branch master will keep pointing to where it has.
- If you do a
git pull, it will do basically fetch (as explained previously) and merge any new changes to your master branch and move the pointer to