What is the difference between ‘git pull’ and ‘git fetch’? [Answered]

In this post, I’ll share the best answers and explanations to understand the difference between ‘git pull’ and ‘git fetch’.

What is the difference between git pull and git fetch?

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

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.

From the Git documentation for git pull:

In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

Difference between git pull and git fetch:

  • When you use pull, Git tries to automatically merge. It is context sensitive, so Git will merge any pulled commits into the branch you are currently working on. pull automatically merges the commits without letting you review them first. If you don’t carefully 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 current branch, you must use merge afterwards.

Answer #3:

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.

Answer #4:

One use case of git fetch is that the following will tell you any changes in the remote branch since your last pull… so you can check before doing an actual pull, which could change files in your current branch and working copy.

git fetch
git diff ...origin

Answer #5:

It cost me a little bit to understand what was the difference, but this is a simple explanation. master in your localhost is a branch.

When you clone a repository you fetch the entire repository to your localhost. This means that at that time you have an origin/master pointer to HEAD and master pointing to the same HEAD.

when you start working and do commits you to advance the master pointer to HEAD + your commits. But the origin/master pointer is still pointing to what it was when you cloned.

So the difference will be:

  • If you do a git fetch it will just fetch all the changes in the remote repository (GitHub) and move the origin/master pointer to HEAD. Meanwhile your local branch master will keep pointing to where it has.
  • If you do a git pull, it will do basically fetch (as explained previously) and merge any new changes to your master branch and move the pointer to HEAD.

git pull vs git fetch- Answer #6:

Sometimes a visual representation helps.

enter image description here

Answer #7:

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.

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

Answer #8:

OK, here is some information about git pull and git fetch, so you can understand the actual differences… in few simple words, fetch gets the latest data, but not the code changes and not going to mess with your current local branch code, but pull get the code changes and merge it your local branch, read on to get more details about each:

git fetch

It will download all refs and objects and any new branches to your local Repository…

Fetch branches and/or tags (collectively, “refs”) from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated (see the description of below for ways to control this behavior).

By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the –tags or –no-tags options or by configuring remote..tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well.

git fetch can fetch from either a single named repository or URL or from several repositories at once if is given and there is a remotes. entry in the configuration file. (See git-config1).

When no remote is specified, by default the origin remote will be used, unless there’s an upstream branch configured for the current branch.

The names of refs that are fetched, together with the object names they point at, are written to .git/FETCH_HEAD. This information may be used by scripts or other git commands, such as git-pull.


git pull

It will apply the changes from remote to the current branch in local…

Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With –rebase, it runs git rebase instead of git merge.

should be the name of a remote repository as passed to git-fetch1. can name an arbitrary remote ref (for example, the name of a tag) or even a collection of refs with corresponding remote-tracking branches (e.g., refs/heads/:refs/remotes/origin/), but usually it is the name of a branch in the remote repository.

Default values for and are read from the “remote” and “merge” configuration for the current branch as set by git-branch –track.


I also create the visual below to show you how git fetch and git pull working together…

git pull and git fetch

Hope you learned something from this post.

Follow Programming Articles for more!

About ᴾᴿᴼᵍʳᵃᵐᵐᵉʳ

Linux and Python enthusiast, in love with open source since 2014, Writer at programming-articles.com, India.

View all posts by ᴾᴿᴼᵍʳᵃᵐᵐᵉʳ →