git pull
calls git fetch
with the appropriate parameters before merging the explicitly fetched heads (or if none the remote branch configured for merge) into the current branch.
The syntax: git fetch <repository> <ref>
where <ref>
is just a branch name with no colon is a ‘one shot’ fetch that doesn’t do a standard fetch of all the tracked branches of the specified remote but instead fetches just the named branch into FETCH_HEAD
.
Update: for Git versions since 1.8.4, if there is a remote tracking branch which tracks the ref that you asked to fetch then the tracking branch will now be updated by fetch
. This change has been made specifically to avoid the confusion that the previous behaviour caused.
When you perform git pull <repository> <ref>
, FETCH_HEAD
is updated as above, then merged into your checked out HEAD
but none of the standard tracking branches for the remote repository will be updated (Git <1.8.4). This means that locally it looks like you are ahead of of the remote branch, whereas in fact you are up to date with it.
Personally I always do git fetch
followed by git merge <remote>/<branch>
because I get to see any warnings about forced updates before I merge, and I can preview what I’m merging in. If I used git pull
a bit more than I do, I would do a plain git pull
with no parameters most of the time, relying on branch.<branch>.remote
and branch.<branch>.merge
to ‘do the right thing’.