What are the differences between git pull and git fetch?

Jonathan Leffler
  • 690,559
  • 129
  • 850
  • 1,220
  • 264,618
  • 120
  • 339
  • 573
  • 407
    I found this well written article about git fetch and git pull it's worth the reading: http://longair.net/blog/2009/04/16/git-fetch-and-merge/ – Marcos Oliveira Sep 16 '10 at 06:57
  • 61
    Our alternative approach has become `git fetch; git reset --hard origin/master` as part of our workflow. It blows away local changes, keeps you up to date with master BUT makes sure you don't just pull in new changes on top on current changes and make a mess. We've used it for a while and it basically feels a lot safer in practice. Just be sure to add/commit/stash any work-in-progress first ! – Michael Durrant May 04 '14 at 14:32
  • 34
    Make sure you know how to use git stash correctly. If you're asking about 'pull' and 'fetch' then maybe 'stash' will also need explaining... – Henry Heleine Dec 09 '14 at 20:09
  • 45
    Lots of folks coming from Mercurial keep using "git pull", thinking it's an equivalent for "hg pull". Which it's not. Git's equivalent of "hg pull" is "git fetch". – Serge Shultz Jun 29 '15 at 10:15
  • A very well written article about git pull vs fetch https://www.freecodecamp.org/news/git-fetch-vs-pull/ – IAmNoob Dec 19 '21 at 19:58
  • git pull pulls from a remote branch and merges it. git fetch only fetches from the remote branch but it does not merge – Murat Özbayraktar Dec 29 '21 at 18:11

38 Answers38


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.

From the Git documentation for git pull:

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

  • 6,908
  • 5
  • 45
  • 60
Greg Hewgill
  • 876,209
  • 175
  • 1,121
  • 1,255
  • 366
    "A "git pull" is what you would do to bring your repository up to date" – Albert Nov 10 '09 at 12:13
  • 217
    @Albert: Yeah, it's weirdly worded. `git pull` will always merge into the **current branch**. So you select which branch you want to pull *from*, and it pulls it into the current branch. The *from* branch can be local or remote; it can even be a remote branch that's not a registered `git remote` (meaning you pass a URL on the `git pull` command line). – intuited Jun 06 '10 at 10:10
  • 14
    Is a "git push" also a "git fetch" (in the other direction) followed by a "git merge"? – Ellen Spertus Mar 16 '11 at 23:51
  • 138
    @espertus: No. Pushing never automatically does a merge. The user is expected to pull, resolving any merge conflicts locally, *then* push back to the remote. – Greg Hewgill Mar 17 '11 at 00:41
  • 38
    If I am at `/home/alice/` and do `git fetch /home/bob`, what parameters should I pass to the subsequent `git merge` ? – ripper234 May 27 '11 at 19:38
  • 118
    Note to people learning Git: `pull` can't actually be emulated by a `fetch` plus a `merge`. I just fetched a change where only a remote branch pointer changes, and `merge` refuses to do anything. `pull`, on the other hand, fast-forwards my tracking branch. – Roman Starkov Sep 28 '12 at 16:23
  • 1
    Is it `git fetch` something like *staging FROM* the remote repository? (I'm somewhat new to version control and Git) – carloswm85 Aug 20 '21 at 20:21
  • `git fetch` mission is to update all your branches, where `git pull` focuses more on the current branch – chill appreciator Jan 12 '22 at 09:54
  • By the way, @GregHewgill, why not to run `git fetch` in a cron job? What's wrong with that? – chill appreciator Jan 12 '22 at 09:55
  • @chillappreciator for one thing, it destroys the safety check that "force push with lease" would have given you. – Mark VY Mar 03 '22 at 21:56
  • 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.

  • 6,908
  • 5
  • 45
  • 60
Mouna Cheikhna
  • 36,744
  • 10
  • 47
  • 68
  • 39
    Agreed, great comment. Which is why I hate git pull. When would it ever make sense to let a revision tool make code edits for you? And isn't that what merging two files is doing? What if those two edits are physically separated in the file, but LOGICALLY at odds? – Lee Dixon May 13 '13 at 18:44
  • I'm not sure if I understand this correctly. Let me know if I'm right: Lets say I have two branches, master and test. test is a branch that I'm working on to experiment something. If I do git fetch, it updates master with the target branch. If I do git pull, it tries to update test with the target branch. Is this right? If not, I think I don't understand what 'local repository' means - I assumed it means my local master. – elexhobby Jun 05 '13 at 19:15
  • 145
    @elexhobby short put, `git fetch` only updates your `.git/` directory (AKA: local repository) and nothing outside `.git/` (AKA: working tree). It does not change your local branches, and it does not touch `master` either. It touches `remotes/origin/master` though (see `git branch -avv`). If you have more remotes, try `git remote update`. This is a `git fetch` for all remotes in one command. – Tino Jul 17 '13 at 06:48
  • 30
    @Tino yours is really the most important point. People may not know that "remote" branches are actually stored as a bunch of hashes in `.git/refs/remotes/origin/`. – Chris Sep 12 '13 at 21:49
  • So, `fetch` command is something like a "commit from the remote to local". Right? – carloswm85 Aug 12 '21 at 20:44
  • @carloswm85 No, In order to retrieve from remote branch(possibly on a separate server) to the remote-tracking branch (i.e. Locally located remote-tracking branch(which is like a proxy) on your local development computer ), we use git fetch – crazyTech Aug 19 '21 at 20:47

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.

Ian Ringrose
  • 50,301
  • 52
  • 209
  • 310
  • 13,838
  • 1
  • 18
  • 10
  • 85
    Technically, the local and remote repositories are really one and the same. In Git, a repository is a [DAG](http://en.wikipedia.org/wiki/Directed_acyclic_graph) of commits pointing to their parents. Branches are, technically, nothing more than meaningful names of commits. The only difference between local and remote branches is that remote ones are prefixed with `remoteName/` [Git from the ground up](http://newartisans.com/2008/04/git-from-the-bottom-up/) is a very good read. Once you get an understanding of how Git works - and it's beautifully _simple_, really - everything just makes sense. – Emil Lundberg Aug 14 '13 at 09:51

Here is Oliver Steele's image of how all it all fits together:

enter image description here

If there is sufficient interest, I suppose I could update the image to add git clone and git merge...

  • 47,014
  • 12
  • 98
  • 129
  • 69,519
  • 55
  • 240
  • 284
  • 178
    An updated image with `git clone` and `git merge` would be very helpful! – MEMark Sep 08 '15 at 14:23
  • 22
    Yes, please add `git merge` - it should clearly show that `merge` called separately is NOT the same as calling `pull` because `pull` is merging from remote only and ignores your local commits in your local branch which is tracking the remote branch being pulled from. – JustAMartin Oct 21 '15 at 19:57
  • 13
    A picture is worth a thousand words! Is the updated image with clone and merge data flow ready somewhere? Any other data flow besides what's already in the diagram? – shikhanshu Nov 25 '15 at 00:27

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

See: https://git-scm.com/docs/git-diff regarding double- and triple-dot syntax in the diff command

  • 405
  • 3
  • 12
  • 5,413
  • 1
  • 13
  • 2

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 you local host. 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 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.
  • 4,393
  • 5
  • 29
  • 43
  • 6,919
  • 3
  • 20
  • 16
  • 16
    origin/master is a local branch that is a COPY of master on origin. When you fetch, you update local:/origin/master. Once you really grok that everything in git is a branch, this makes a lot of sense and is a very powerful way to maintain different changesets, make quick local branches, merge and rebase, and generally get a lot of value out of the cheap branching model. – cam8001 May 28 '13 at 16:00

Sometimes a visual representation helps.

enter image description here

  • 1,537
  • 1
  • 13
  • 20
  • 6,550
  • 2
  • 34
  • 57
  • 26
    I think the picture got to show that it affects the local repo too. That's is, Git pull is a combination of affecting the local repo and working copy. Right now it seems it just affect the working copy. – nonopolarity Feb 14 '16 at 18:51


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.


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.


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


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/

  • 23
  • 1
  • 4
  • 72,354
  • 69
  • 220
  • 338
git-pull - Fetch from and merge with another repository or a local branch

git pull   …

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.

Vinko Vrsalovic
  • 251,156
  • 51
  • 323
  • 366

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
  • 1,228
  • 15
  • 31
Antonio Bardazzi
  • 2,717
  • 1
  • 17
  • 19
  • 37
    You probably want to skip the pull and just do a "git rebase origin" as the last step since you already fetched the changes. The reason is that someone could have pushed changes in the time since you did the fetch and these would not have been in fetch that you did the diff review on. – Justin Ohms Aug 31 '12 at 20:02

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

Noor A Shuvo
  • 2,361
  • 1
  • 19
  • 39
  • 91,333
  • 25
  • 257
  • 157

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.

  • 3,451
  • 3
  • 27
  • 35

enter image description here

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

  • 1,741
  • 1
  • 15
  • 19
  • 20
    People, click on the link to interact with the different columns. This cheatsheet is the best resource I've seen to fully understand the differences between each command. – M. Luisa Carrión Oct 04 '16 at 00:41
  • The image needs to be updated, as the reset operation is wrongly connected to the remote repo, while it should be connected to the local repo. This is fixed on the linked site. – Cristik Oct 22 '21 at 05:13


In speaking of pull & fetch in the above answers, I would like to share an interesting trick,

git pull --rebase

This above command is the most useful command in my git life which saved a lots of time.

Before pushing your new commits to server, try this command and it will automatically sync latest server changes (with a fetch + merge) and will place your commit at the top in git log. No need to worry about manual pull/merge.

Find details at: http://gitolite.com/git-pull--rebase

  • 1
  • 1
Sazzad Hissain Khan
  • 32,788
  • 22
  • 157
  • 217

I like to have some visual representation of the situation to grasp these things. Maybe other developers would like to see it too, so here's my addition. I'm not totally sure that it all is correct, so please comment if you find any mistakes.

                                         LOCAL SYSTEM
                  . =====================================================    
================= . =================  ===================  =============
(ORIGIN)          . (CACHED)           
for example,      . mirror of the      
a github repo.    . remote repo
Can also be       .
multiple repo's   .
FETCH  *------------------>*
Your local cache of the remote is updated with the origin (or multiple
external sources, that is git's distributed nature)
PULL   *-------------------------------------------------------->*
changes are merged directly into your local copy. when conflicts occur, 
you are asked for decisions.
COMMIT            .                             *<---------------*
When coming from, for example, subversion, you might think that a commit
will update the origin. In git, a commit is only done to your local repo.
PUSH   *<---------------------------------------*
Synchronizes your changes back into the origin.

Some major advantages for having a fetched mirror of the remote are:

  • Performance (scroll through all commits and messages without trying to squeeze it through the network)
  • Feedback about the state of your local repo (for example, I use Atlassian's SourceTree, which will give me a bulb indicating if I'm commits ahead or behind compared to the origin. This information can be updated with a GIT FETCH).
Justus Romijn
  • 14,683
  • 4
  • 49
  • 61

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

enter image description here

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 the main branch can lead to conflict and may cause your Module D to malfunction.

enter image description here

To avoid such issues and to work parallel with the original progress of the project there 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.

enter image description here

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.

enter image description here

2. Git Pull- This will update your local branch with the origin/main branch i.e. actually what it does is a 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.

enter image description here

Aman Tiwari
  • 1,285
  • 1
  • 9
  • 13

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.

  • 6,773
  • 9
  • 39
  • 62
pn1 dude
  • 3,998
  • 5
  • 28
  • 25

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.

  • 6,920
  • 3
  • 29
  • 41

In simple terms, if you were about to hop onto a plane without any Internet connection...before departing you could just do git fetch origin <branch>. It would fetch all the changes into your computer, but keep it separate from your local development/workspace.

On the plane, you could make changes to your local workspace and then merge it with what you've previously fetched and then resolve potential merge conflicts all without a connection to the Internet. And unless someone had made new changes to the remote repository then once you arrive at the destination you would do git push origin <branch> and go get your coffee.

From this awesome Atlassian tutorial:

The git fetch command downloads commits, files, and refs from a remote repository into your local repository.

Fetching is what you do when you want to see what everybody else has been working on. It’s similar to SVN update in that it lets you see how the central history has progressed, but it doesn’t force you to actually merge the changes into your repository. Git isolates fetched content as a from existing local content, it has absolutely no effect on your local development work. Fetched content has to be explicitly checked out using the git checkout command. This makes fetching a safe way to review commits before integrating them with your local repository.

When downloading content from a remote repository, git pull and git fetch commands are available to accomplish the task. You can consider git fetch the 'safe' version of the two commands. It will download the remote content, but not update your local repository's working state, leaving your current work intact. git pull is the more aggressive alternative, it will download the remote content for the active local branch and immediately execute git merge to create a merge commit for the new remote content. If you have pending changes in progress this will cause conflicts and kickoff the merge conflict resolution flow.

With git pull:

  • You don't get any isolation.
  • It doesn't need to be explicitly checked out. Because it implicitly does a git merge.
  • The merging step will affect your local development and may cause conflicts
  • It's basically NOT safe. It's aggressive.
  • Unlike git fetch where it only affects your .git/refs/remotes, git pull will affect both your .git/refs/remotes and .git/refs/heads/

Hmmm...so if I'm not updating the working copy with git fetch, then where am I making changes? Where does Git fetch store the new commits?

Great question. First and foremost, the heads or remotes don't store the new commits. They just have pointers to commits. So with git fetch you download the latest git objects (blob, tree, commits. To fully understand the objects watch this video on git internals), but only update your remotes pointer to point to the latest commit of that branch. It's still isolated from your working copy, because your branch's pointer in the heads directory hasn't updated. It will only update upon a merge/pull. But again where? Let's find out.

In your project directory (i.e., where you do your git commands) do:

  1. ls. This will show the files & directories. Nothing cool, I know.

  2. Now do ls -a. This will show dot files, i.e., files beginning with . You will then be able to see a directory named: .git.

  3. Do cd .git. This will obviously change your directory.

  4. Now comes the fun part; do ls. You will see a list of directories. We're looking for refs. Do cd refs.

  5. It's interesting to see what's inside all directories, but let's focus on two of them. heads and remotes. Use cd to check inside them too.

  6. Any git fetch that you do will update the pointer in the /.git/refs/remotes directory. It won't update anything in the /.git/refs/heads directory.

  7. Any git pull will first do the git fetch, update items in the /.git/refs/remotes directory, then merge with your local and then change the head inside the /.git/refs/heads directory.

A very good related answer can also be found in Where does 'git fetch' place itself?.

Also, look for "Slash notation" from the Git branch naming conventions post. It helps you better understand how Git places things in different directories.

To see the actual difference

Just do:

git fetch origin master
git checkout master

If the remote master was updated you'll get a message like this:

Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

If you didn't fetch and just did git checkout master then your local git wouldn't know that there are 2 commits added. And it would just say:

Already on 'master'
Your branch is up to date with 'origin/master'.

But that's outdated and incorrect. It's because git will give you feedback solely based on what it knows. It's oblivious to new commits that it hasn't pulled down yet...

Is there any way to see the new changes made in remote while working on the branch locally?

Some IDEs (e.g. Xcode) are super smart and use the result of a git fetch and can annotate the lines of code that have been changed in remote branch of your current working branch. If that line has been changed by both local changes and remote branch, then that line gets annotated with red. This isn't a merge conflict. It's a potential merge conflict. It's a headsup that you can use to resolve the future merge conflict before doing git pull from the remote branch.

enter image description here

Fun tip:

If you fetched a remote branch e.g. did:

git fetch origin feature/123

Then this would go into your remotes directory. It's still not available to your local directory. However, it simplifies your checkout to that remote branch by DWIM (Do what I mean):

git checkout feature/123

you no longer need to do:

git checkout -b feature/123 origin/feature/123

For more on that read here

  • 27,647
  • 14
  • 138
  • 243

git fetch pulls down the code from the remote server to your tracking branches in your local repository. If your remote is named origin (the default) then these branches will be within origin/, for example origin/master, origin/mybranch-123, etc. These are not your current branches, they are local copies of those branches from the server.

git pull does a git fetch but then also merges the code from the tracking branch into your current local version of that branch. If you're not ready for that changes yet, just git fetch first.

Michael Durrant
  • 88,258
  • 87
  • 298
  • 466

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.

Peter Mortensen
  • 29,726
  • 21
  • 98
  • 124
  • 1,049
  • 8
  • 6

Git Fetch

You download changes to your local branch from origin through fetch. Fetch asks the remote repo for all commits that others have made but you don't have on your local repo. Fetch downloads these commits and adds them to the local repository.

Git Merge

You can apply changes downloaded through fetch using the merge command. Merge will take the commits retrieved from fetch and try to add them to your local branch. The merge will keep the commit history of your local changes so that when you share your branch with push, Git will know how others can merge your changes.

Git Pull

Fetch and merge run together often enough that a command that combines the two, pull, was created. Pull does a fetch and then a merge to add the downloaded commits into your local branch.

Pinkesh Sharma
  • 2,258
  • 18
  • 16

The only difference between git pull and git fetch is that :

git pull pulls from a remote branch and merges it.

git fetch only fetches from the remote branch but it does not merge

i.e. git pull = git fetch + git merge ...

  • 1,776
  • 25
  • 28
Rohitashv Singhal
  • 4,339
  • 13
  • 54
  • 102

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

Pawel Furmaniak
  • 4,214
  • 3
  • 28
  • 33

The git pull command is actually a shortcut for git fetch followed by the git merge or the git rebase command depending on your configuration. You can configure your Git repository so that git pull is a fetch followed by a rebase.

  • 643
  • 3
  • 16
  • 5,931
  • 4
  • 46
  • 49

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.

Marcus Thornton
  • 5,333
  • 5
  • 44
  • 47

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.

  • 27,883
  • 10
  • 60
  • 70

A simple Graphical Representation for Beginners,

enter image description here


git pull  

will fetch code from repository and rebase with your local... in git pull there is possibility of new commits getting created.

but in ,

git fetch

will fetch code from repository and we need to rebase it manually by using git rebase

eg: i am going to fetch from server master and rebase it in my local master.

1) git pull ( rebase will done automatically):

git pull origin master

here origin is your remote repo master is your branch

2) git fetch (need to rebase manually):

git fetch origin master

it will fetch server changes from origin. and it will be in your local until you rebase it on your own. we need to fix conflicts manually by checking codes.

git rebase origin/master

this will rebase code into local. before that ensure you're in right branch.

Mohideen bin Mohammed
  • 16,261
  • 7
  • 96
  • 108

git pull == ( git fetch + git merge)

git fetch does not changes to local branches.

If you already have a local repository with a remote set up for the desired project, you can grab all branches and tags for the existing remote using git fetch . ... Fetch does not make any changes to local branches, so you will need to merge a remote branch with a paired local branch to incorporate newly fetch changes. from github

  • 8,033
  • 3
  • 30
  • 21

Actually Git maintains a copy of your own code and the remote repository.

The command git fetch makes your local copy up to date by getting data from remote repository. The reason we need this is because somebody else might have made some changes to the code and you want to keep yourself updated.

The command git pull brings the changes in the remote repository to where you keep your own code. Normally, git pull does this by doing a ‘git fetch’ first to bring the local copy of the remote repository up to date, and then it merges the changes into your own code repository and possibly your working copy.

  • 5,144
  • 12
  • 47
  • 80
  • 441
  • 5
  • 8
git pull = git fetch + git merge 
Saqib R.
  • 2,709
  • 2
  • 25
  • 20

git pull

It performs two functions using a single command.

It fetches all the changes that were made to the remote branch and then merges those changes into your local branch. You can also modify the behaviour of pull by passing --rebase. The difference between merge and rebase can be read here

git fetch

Git fetch does only half the work of git pull. It just brings the remote changes into your local repo but does not apply them onto your branches.You have to explicitly apply those changes. This can be done as follows:

git fetch
git rebase origin/master
  • 1
  • 1
Animesh Sharma
  • 3,060
  • 1
  • 15
  • 30

One must keep in mind the nature of git. You have remotes and your local branches ( not necessarily the same ) . In comparison to other source control systems this can be a bit perplexing.

Usually when you checkout a remote a local copy is created that tracks the remote.

git fetch will work with the remote branch and update your information.

It is actually the case if other SWEs are working one the same branch, and rarely the case in small one dev - one branch - one project scenarios.

Your work on the local branch is still intact. In order to bring the changes to your local branch you have to merge/rebase the changes from the remote branch.

git pull does exactly these two steps ( i.e. --rebase to rebase instead of merge )

If your local history and the remote history have conflicts the you will be forced to do the merge during a git push to publish your changes.

Thus it really depends on the nature of your work environment and experience what to use.

  • 2,889
  • 12
  • 28

All branches are stored in .git/refs

All local branches are stored in .git/refs/heads

All remote branches are stored in .git/refs/remotes

The git fetch command downloads commits, files, and refs from a remote repository into your local repo. Fetching is what you do when you want to see what everybody else has been working on.

So when you do git fetch all the files, commits, and refs are downloaded in

this directory .git/refs/remotes

You can switch to these branches to see the changes.

Also, you can merge them if you want.

git pull just downloads these changes and also merges them to the current branch.


If you want see the work of remote branch dev/jd/feature/auth, you just need to do

git fetch origin dev/jd/feature/auth

to see the changes or work progress do,

git checkout dev/jd/feature/auth

But, If you also want to fetch and merge them in the current branch do,

git pull origin dev/jd/feature/auth

If you do git fetch origin branch_name, it will fetch the branch, now you can switch to this branch you want and see the changes. Your local master or other local branches won't be affected. But git pull origin branch_name will fetch the branch and will also merge to the current branch.

  • 2,469
  • 1
  • 19
  • 43

Simple explanation:

git fetch

fetches the metadata. If you want to check out a recently created branch you may want to do a fetch before checkout.

git pull

Fetches the metadata from remote and also moved the files from remote and merge on to the branch

Akash Yellappa
  • 1,520
  • 20
  • 18

Git Fetch

Helps you to get known about the latest updates from a git repository. Let's say you working in a team using GitFlow, where team working on multiple branches ( features ). With git fetch --all command you can get known about all new branches within repository.

Mostly git fetch is used with git reset. For example you want to revert all your local changes to the current repository state.

git fetch --all // get known about latest updates
git reset --hard origin/[branch] // revert to current branch state

Git pull

This command update your branch with current repository branch state. Let's continue with GitFlow. Multiple feature branches was merged to develop branch and when you want to develop new features for the project you must go to the develop branch and do a git pull to get the current state of develop branch

Documentation for GitFlow https://gist.github.com/peterdeweese/4251497

Andrei Todorut
  • 3,711
  • 2
  • 15
  • 25

This graphic could be of help. git pull is essentially equivalent to git fetch then git merge

This graphic could be of help. git pull is essentially equivalent to git fetch then git merge

  • 964
  • 1
  • 9
  • 24
Piaget Hadzizi
  • 453
  • 3
  • 13

By Definition:

Git Fetch:

Git fetch is a command that allows you to download objects from another repository.

Git Pull:

Git pull is a command that allows you to fetch from and integrate with another repository or local branch.

Key Differences

When should you use Git Fetch?

If you only want to see all of the current branches and changes in your remote repository, Git fetch can get you all of the information you need without actually making any local changes to your work.

  • This gives you time to decide on the best course of action for incorporating your changes, such as merging them in or fast-forwarding your local branch.


$ git fetch origin

When should you use Git Pull?

Git pull is a desirable action when you have complete context about the changes you will be getting from your remote repository and adding to your local copy.


$ git pull origin master


Both are used to download new data from a remote repository.

Why You need these commands?

for example, there were changes recently made to your remote repository and you want to incorporate them into your local copy. You have a few options here; the two most common actions to get changes from your remote are Git pull and Git fetch.

Points To Consider:


  • Its main function is to fetch the content.
  • It has only command-line syntax.


  • Its main function is a combination of fetch and merges the content.
  • It has command-line syntax as well as a pull request to post the changes.

My Opinion:

The Git Pull is better than git fetch as it does the functionality of two commands. However, Git Fetch is considered a safer one compared to Git Pull.

Jonathan Leffler
  • 690,559
  • 129
  • 850
  • 1,220
  • 705
  • 3
  • 12
  • 17
  • Welcome to Stack Overflow. If you decide to answer an older question that has well established and correct answers, adding a new answer late in the day may not get you any credit. If you have some distinctive new information, or you're convinced the other answers are all wrong, by all means add a new answer, but 'yet another answer' giving the same basic information a long time after the question was asked usually won't earn you much credit. – Jonathan Leffler Jan 20 '22 at 16:32