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

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.

Answer 2

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

Answer 3

What is the difference between git pull and git fetch?

To understand this, you first need to understand that your local git maintains not only your local repository, but it also maintains a local copy of the remote repository.

git fetch brings your local copy of the remote repository up to date. For example, if your remote repository is GitHub - you may want to fetch any changes made in the remote repository to your local copy of it the remote repository. This will allow you to perform operations such as compare or merge.

git pull on the other hand will bring down the changes in the remote repository to where you keep your own code. Typically, git pull will do a git fetch first to bring the local copy of the remote repository up to date, and then it will merge the changes into your own code repository and possibly your working copy.

Answer 4

git pull = git fetch + git 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

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.

• git fetch is the command that says "bring my local copy of the remote repository up to date."

• git pull says "bring the changes in the remote repository to 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.