What is the difference between 'git pull' and 'git fetch'?

Answer 1

Git obtains the branch of the latest version from the remote to the local using two commands:

1. git fetch: Git is going to get the latest version from remote to local, but it do not automatically merge.      git fetch origin master git log -p master..origin/master git merge origin/master

        The commands above mean that download latest version of the main branch from origin from the remote to origin master branch. And then compares the local master branch and origin master branch. Finally, merge.

2. git pull: Git is going to get the latest version from the remote and merge into the local.

       git pull origin master

        The command above is the equivalent to git fetch and git merge. In practice, git fetch maybe more secure because before the merge we can see the changes and decide whether to merge.

Answer 2

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.

Answer 3

• 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.

Answer 4

Briefly

git fetch is similar to pull but doesn't merge. i.e. it fetches remote updates (refs and objects) but your local stays the same (i.e. origin/master gets updated but master stays the same) .

git pull pulls down from a remote and instantly merges.

More

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.

This blog post was useful:

The difference between git pull, git fetch and git clone (and git rebase) - Mike Pearce

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

====

UPDATE

I thought I'd update this to show how you'd actually use this in practice.

1. Update your local repo from the remote (but don't merge):

   git fetch 
   

2. After downloading the updates, let's see the differences:

   git diff master origin/master 
   

3. If you're happy with those updates, then merge:

   git pull
   

Notes:

On step 2: For more on diffs between local and remotes, see: How to compare a local git branch with its remote branch?

On step 3: It's probably more accurate (e.g. on a fast changing repo) to do a git rebase origin here. See @Justin Ohms comment in another answer.

See also: http://longair.net/blog/2009/04/16/git-fetch-and-merge/

Answer 5

The short and easy answer is that git pull is simply git fetch followed by git merge.

It is very important to note that git pull will automatically merge whether you like it or not. This could, of course, result in merge conflicts. Let's say your remote is origin and your branch is master. If you git diff origin/master before pulling, you should have some idea of potential merge conflicts and could prepare your local branch accordingly.

In addition to pulling and pushing, some workflows involve git rebase, such as this one, which I paraphrase from the linked article:

git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch

If you find yourself in such a situation, you may be tempted to git pull --rebase. Unless you really, really know what you are doing, I would advise against that. This warning is from the man page for git-pull, version 2.3.5:

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.

Answer 6

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 rebase origin master