What is the difference between 'git pull'

Question

Moderator Note: Given that this question has already had sixty-seven answers posted to it (some of them deleted), consider whether or not you are contributing anything new before posting another one.

What are the differences between git pull and git fetch?

Answer 1

This interactive graphical representation is very helpful in understanging git: http://ndpsoftware.com/git-cheatsheet.html

git fetch just "downloads" the changes from the remote to your local repository. git pull downloads the changes and merges them into your current branch. "In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD."

Answer 2

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 remote-tracking branches under refs/remotes/<remote>/.

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

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

Git documentation: git pull

Answer 3

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.

Answer 4

Git allows chronologically older commits to be applied after newer commits. Because of this, the act of transferring commits between repositories is split into two steps:

1. Copying new commits from remote branch to copy of this remote branch inside local repo.

   (repo to repo operation) master@remote >> remote/origin/master@local

2. Integrating new commits to local branch

   (inside-repo operation) remote/origin/master@local >> master@local

There are two ways of doing step 2. You can:

1. Fork local branch after last common ancestor and add new commits parallel to commits which are unique to local repository, finalized by merging commit, closing the fork.
2. Insert new commits after last common ancestor and reapply commits unique to local repository.

In git terminology, step 1 is git fetch, step 2 is git merge or git rebase

git pull is git fetch and git merge

Answer 5

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

The Difference between GIT Fetch and GIT Pull can be explained with the following scenario: (Keeping in mind that pictures speak louder than words!, I have provided pictorial representation)

Let's take an example that you are working on a project with your team members. So their will be one main Branch of the project and all the contributors must fork it to their own local repository and then work on this local branch to modify/Add modules then push back to the main branch.

So, Initial State of the two Branches when you forked the main project on your local repository will be like this- (A, B and C are Modules already completed of the project)

Now, you have started working on the new module (suppose D) and when you have completed the D module you want to push it to the main branch, But meanwhile what happens is that one of your teammates has developed new Module E, F and modified C.
So now what has happened is that your local repository is lacking behind the original progress of the project and thus pushing of your changes to main branch can lead to conflict and may cause your Module D to malfunction.

To avoid such issues and to work parallel with the original progress of the project their are Two ways:

1. Git Fetch- This will Download all the changes that have been made to the origin/main branch project which are not present in your local branch. And will wait for the Git Merge command to apply the changes that have been fetched to your Repository or branch.

So now You can carefully monitor the files before merging it to your repository. And you can also modify D if required because of Modified C.

2. Git Pull- This will update your local branch with the origin/main branch i.e. actually what it does is combination of Git Fetch and Git merge one after another. But this may Cause Conflicts to occur, so it’s recommended to use Git Pull with a clean copy.