What's the difference between 'git pull' and 'git fetch'?
47
What's the difference between git pull and git fetch?
improve this question | comment
Titus Fadel Created at: 2013-11-13 17:07:50 UTC By Titus Fadel
I found this well written article about git fetch and git pull it's worth the reading: longair.net/blog/2009/04/16/git-fetch-and-merge - Hulda Zboncak
You may also find this helpful: stackoverflow.com/a/9204499/631619 - Kristofer Miller IV
16 Answers
0
git pull == ( git fetch + git merge) 

git fetch does not changes to local branches.

If you already have a local repository with a remote set up for the desired project, you can grab all branches and tags for the existing remote using git fetch . ... Fetch does not make any changes to local branches, so you will need to merge a remote branch with a paired local branch to incorporate newly fetch changes. from github
0
You can fetch from a remote repository, see the differences and then pull or merge.

This is an example for a remote repository called origin and a branch called master tracking the remote branch origin/master:

git checkout master                                                  
git fetch                                        
git diff origin/master
git pull --rebase origin master

0
In the simplest terms, git pull does a git fetch followed by a git merge.

You can do a git fetch at any time to update your local copy of a remote branch. This operation never changes any of your own branches 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).

A git pull is what you would do to bring your repository up to date with a remote repository.
0
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.  pull automatically merges the commits without letting you review them first. If you don’t closely manage your branches you may run into frequent conflicts.
When you 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 merge.
0
It is a bit silly to add anything here since this is an old question, but I'll add it anyway for the benefit of other people who may come upon this.

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.

The command "git fetch" is the command that says "bring my local copy of the remote repository up to date." The command "git pull" says "bring the changes in the remote repository where I keep my own code." Normally "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.
0
It cost me a little bit to understand what was the difference is, but for me this is a simple explanation. Just think that "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 HEAD.

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 fetch" it 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 the same thing, but it will try to merge whatever you it pulled into your master branch.
0
git-pull - Fetch from and merge with another repository or a local branch
SYNOPSIS

git pull   …
DESCRIPTION

Runs git-fetch with the given parameters, and calls git-merge to merge the 
retrieved head(s) into the current branch. With --rebase, calls git-rebase 
instead of git-merge.

Note that you can use . (current directory) as the <repository> to pull 
from the local repository — this is useful when merging local branches 
into the current branch.

Also note that options meant for git-pull itself and underlying git-merge 
must be given before the options meant for git-fetch.


You would pull if you want the histories merged, you'd fetch if you just 'want the codez' as some person has been tagging some articles around here.
0
Be careful with git pull --rebase. This warning is from the git-pull man page:

This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history already. Do not use this option unless you have read git-rebase(1) carefully.
0
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

0
I have struggled with this as well.  In fact I got here with a google search of exactly the same question.  Reading all these answers finally painted a picture in my head and I decided to try to get this down looking at the state of the 2 repositories and 1 sandbox and actions preformed over time while watching the version of them.  So here is what I came up with.  Please correct me if I messed up anywhere.

The three repos with a fetch

---------------------     -----------------------     -----------------------
- Remote Repo       -     - Remote Repo         -     - Remote Repo         -
-                   -     - gets pushed         -     -                     -
- @ R01             -     - @ R02               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Repo        -     - Local Repo          -     - Local Repo          -
- pull              -     -                     -     - fetch               -
- @ R01             -     - @ R01               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Sandbox     -     - Local Sandbox       -     - Local Sandbox       -
- Checkout          -     - new work done       -     -                     -
- @ R01             -     - @ R01+              -     - @R01+               -
---------------------     -----------------------     -----------------------


The three repos with a pull

---------------------     -----------------------     -----------------------
- Remote Repo       -     - Remote Repo         -     - Remote Repo         -
-                   -     - gets pushed         -     -                     -
- @ R01             -     - @ R02               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Repo        -     - Local Repo          -     - Local Repo          -
- pull              -     -                     -     - pull                -
- @ R01             -     - @ R01               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Sandbox     -     - Local Sandbox       -     - Local Sandbox       -
- Checkout          -     - new work done       -     - merged with R02     -
- @ R01             -     - @ R01+              -     - @R02+               -
---------------------     -----------------------     -----------------------


This helped me understand why a fetch is pretty important.
0
I found this blog post useful:

http://blog.mikepearce.net/2010/05/18/the-difference-between-git-pull-git-fetch-and-git-clone-and-git-rebase/

It covers git pull, git fetch, git clone and git rebase.

git pull pulls down from a remote and instantly merges.

git fetch is similar to pull but doesn't merge. 

git clone clones a repo.

git rebase saves stuff from your current branch that isn't in the upstream branch to a temporary area. Your branch is now the same as before you started your changes. So, git pull -rebase will pull down the remote changes, rewind your local branch, replay your changes over the top of your current branch one by one until you're up-to-date.

Also, git branch -a will show you exactly what’s going on with all your branches - local and remote.
0
The documentation of www.git-scm.com has been improved a lot. I encourage you to read the article 3.5 Git Branching - Remote Branches. It explains a lot of things we should know to work better with Git.
0
git fetch will retrieve remote branches so that you can git diff or git merge them with the current branch. git pull will run fetch on the remote brach tracked by the current branch and then merge the result. You can use git fetch to see if there are any updates to the remote branch without necessary merging them with your local branch.
0
We simply say:

git pull == git fetch + git merge


If you run git pull, you do not need to merge the data to local. If you run git fetch, it means you must run git merge for getting the latest code to your local machine. Otherwise, the local machine code would not be changed without merge. 

So in the Git Gui, when you do fetch, you have to merge the data. Fetch itself won't make the code changes at your local. You can check that when you update the code by fetching
once fetch and see; the code it won't change. Then you merge... You will see the changed code.
0
The only difference between git pull and git fetch is that :

git pull pulls from a remote branch and merges it.

git fetch only fetches from the remote branch but it does not merge

i.e. git pull = git fetch + git merge ...
0
git fetch pulls down the code from the remote server to your tracking branches.  These are not your current branches, they are local copies of the branches from the server.

git pull does a git fetch but then also merges the code from the tracking branch into your current local branch.  If you're not in the 'right' branch at the time this can be disastrous, so that's one reason why many of us git fetch first.
Your Answer