Git: pull vs. fetch → pull

Question

I could never get a clear answer to this question.

Over time, and on the advice of a colleague, I did this:

git fetch origin git pull origin <mybranch> 

They told me (and saw) that git pull does not behave as if you hadn't done git fetch at first. You do not receive any deleted changes.

But all I see on the Internet is that git pull is the equivalent of git fetch , followed by git merge . If that were the case, git pull would git fetch , and I would not need an explicit git fetch in the first place, right? But this does not seem to be the case.

So, I'm looking for some explicit documentation that describes the observed behavior of git pull . (I know that I probably also get a lot of tips to switch to git fetch git merge ; this is also good, but I'm really interested in git pull .)

Answer 1

We should probably close this as a duplicate, but before that happens let me see if I can do this.

While git pull really git fetch followed by git merge (or git rebase ), the exact difference is how git pull works git fetch .

In particular:

$ git pull

or

$ git pull remote-name branch-name

(or various similar options), not just git fetch , not git fetch remote-name , but git fetch remote-name branch-name .

This has less difference since Git is version 1.8.4 than it was before this version:

• git fetch origin master , unlike git fetch origin or git fetch did not update refs/remotes/origin/master ; it was an early decision to develop the update of remote tracking branches predictable, but in practice it turns out that people find it more convenient for an opportunistic update, when we have and we update them when we run git push , which in any case violates the original “predictability”.

In other words, if git pull decides to run git fetch origin master , it will update origin/master in your repository, but only if you are not using older versions of Git, such as those included in some unnamed Linux distributions.

If you run git fetch origin , you will get all the remote tracking branches (assuming you have a reasonable configuration, which is used by default even in older versions of Git). If you run git fetch origin master you will only get origin/master and again only if your Git is not too ridiculously outdated. Since git pull runs a four-word variant, it updates only one branch of remote tracking or not.

Answer 2

I was told (and seen) that git pull does not behave the same unless you first do git fetch. You do not receive any deleted changes.

This is usually not the case, and git pull pulls the state from the remote.

But all I see on the Internet is that git pull is the equivalent of git fetch, followed by git merge. If so,

this is!

Referring to the git-pull manual page:

Includes changes from the remote repository to the current branch. In default mode, git pull is short for git fetch, followed by git merge FETCH_HEAD.

I think this solves.

So I'm looking for some explicit documentation

 $ git help pull 

Answer 3

git pull is a fetch followed by a git merge. (or you can reinstall instead with the --rebase option). So you do not need to do "git fetch" before "git pull"

type 'git help fetch' and 'git help pull' for description

git fetch goes to the named repository, gets the object referenced (usually a commit), gets it and all its dependent objects, and saves it in the named remote tracking branch. Then you can merge or reinstall. 'git merge origin / master' or you can just view it with <git checkout origin / master '