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

10 503

2 061

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?


Posted 2008-11-15T09:51:09.660

Reputation: 102 661


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 – 2010-09-16T06:57:47.860

35Our 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 – 2014-05-04T14:32:18.200

18Make 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 – 2014-12-09T20:09:04.670

25Lots 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 – 2015-06-29T10:15:53.497

4git fetch command fetching updated code with branch and also will get newly added branches in your local, git pull command fetch only updated code of current branch only – Kartik Patel – 2017-07-27T11:43:31.680

@MichaelDurrant FWIW, that is equivalent to git pull --ff-only, although I don't remember if it was available in 2014. – jpaugh – 2018-05-21T21:16:18.660

To note, git fetch has no correspondent in traditional source control systems (that I'm aware of). The main goal of using git fetch (to "see what happened in remote") is achieved e.g. in SVN with a merge --dry-run. It should be part of the basic workflow, that before you pull, you get an idea of what changes you are pulling, particularly those changes that would conflict with your local ones. – haelix – 2018-09-06T18:16:44.633


8 758

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

Greg Hewgill

Posted 2008-11-15T09:51:09.660

Reputation: 657 778

296"A "git pull" is what you would do to bring your repository up to date" <- isn't the repository update already done by fetch? don't you mean it brings your local branches up-to-date with the remote branches?

To the merge: It merges the remote branches with your local copies of those branches, or what exactly does it merge here? – Albert – 2009-11-10T12:13:21.780

91Note 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 – 2012-09-28T16:23:00.897

12Lets imagine that I have only a master branch. Which EXACT commands (with all the necessary options) should replace git pull command? – Paul – 2013-01-25T15:16:40.227

@espertus - FYI if you uses Git Extensions you can do auto-pull on before push if the push is rejected. – Laksitha Ranasingha – 2013-01-31T12:36:29.937

4Alternatively, you can update your git repo with remote repo by doing git fetch followed by git rebase origin/master – abumusamq – 2013-02-07T12:16:32.853

6Why isn't it git update? – Sophivorus – 2013-03-24T17:21:45.537

7@romkyns I don't quite follow what you mean there. Could you please explain what "I just fetched a change where only a remote branch pointer changes, and merge refuses to do anything." means? – viki.omega9 – 2013-05-26T17:15:33.113

2@dev-inside Or just do git pull --rebase – Michael Mior – 2013-05-26T21:06:41.247

176@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 – 2010-06-06T10:10:08.973

29git pull is shorthand for git fetch followed by git merge FETCH_HEAD. – Nikita – 2014-04-15T18:51:59.530

4This operation never changes any of your own local branches under refs/heads - what does it do then? I still don't understand well. – アレックス – 2014-06-13T01:39:10.780

3@AlexanderSupertramp: git fetch updates the remote tracking branches. These are the branches listed starting with remotes/ in git branch -a, and are a copy of the branches on the remote repository. – Greg Hewgill – 2014-06-13T01:41:54.403

@GregHewgill, how does it updates them? It seems like you're implying it pushes something to the remote branches. – アレックス – 2014-06-13T04:38:41.987

6@AlexanderSupertramp: I'm not saying that at all. Your normal branches are under refs/heads. Remote tracking branches are under refs/remotes. The git fetch command updates your remote tracking branches under refs/remotes and does not change anything under refs/heads. – Greg Hewgill – 2014-06-13T07:16:32.740

Locally I keep only local branches and edit only them, correct? What do you mean by "updates remotes" branches? – アレックス – 2014-06-13T08:00:03.397

4@AlexanderSupertramp: Please ask a new question if you are having trouble understanding Git terminology. The comments section is not the right place to have this discussion. Thanks. – Greg Hewgill – 2014-06-13T08:02:47.747

3The key distinction here is refs/remote and refs/heads. heads refers to your local working branch, whereas remote refers to the branch pointing to the remote, with information since your last git fetch origin. – JohnMerlino – 2014-06-28T16:22:59.510

@romkyns "pull can't actually be emulated by a fetch plus a merge" Actually, yes it can. I do it all the time. – Ajedi32 – 2014-08-20T18:23:29.770

1@Ajedi32 some of what pull does can be emulated by those two, yes. But not the entire command in all possible circumstances. – Roman Starkov – 2014-08-22T14:22:17.500

1@romkyns True. Perhaps I didn't understand the circumstance mentioned in your comment, but fast-forwards can definitely be done with git merge. – Ajedi32 – 2014-08-23T03:09:18.473

"while also updating your other remote-tracking branches" What does this mean? – user2906759 – 2014-09-11T12:50:58.293

4@user2906759: Git keeps track, in your local repository, of the state of all the branches on a remote. Google "remote tracking branches" for lots of info about this. – Greg Hewgill – 2014-09-11T18:52:47.100

Something I've been playing around with. I often 'git fetch' to pull the changes. If you then 'git pull' though it appears that it goes to the network again. Instead, AFTER the fetch, I've been running 'git merge @{u}' which I think merges in the head of the configured tracking branch without going to the network again. Seems faster. Warning - I'm still experimenting! – Damien Sawyer – 2014-12-16T20:53:29.070

2Is this the true workings of git pull? Or simply a pseudo-similar behavior? Has anyone looked at the implementation of git pull as really using git fetch and git merge under the hood? Or does git pull has it's own internal logic, which in most situations performs similar operations as to what fetch followed by merge does, but possibly not in all of them? – Didier A. – 2015-01-05T16:44:28.263

1You mentioned a cron job to automatically do git fetch. I think SourceTree has an option to periodically run git fetch, since I seem to notice remote updates in the visual interface even though I didn't run any explicit commands. – Scott – 2015-01-22T14:16:43.017

2Now I understand why pull from master into the current branch won't update the branch even if master has new local commits merged in. It's because the merge in pull is merging from FETCH_HEAD and completely ignoring my local master! I wish this important difference was better emphasized in all tutorials which mention pull and claim that it is almost the same as fetch + merge. "Almost" is really important if you are pulling and hoping to do all-in-one - fetch + merge from remote AND merge from local. Surprise - pull does not merge from local branch! – JustAMartin – 2015-10-21T19:53:06.193

Does "update remote-tracking branches" mean that all the branches up on the repository now are available on your local repository? – Jwan622 – 2016-03-25T16:16:42.983

@Jwan622: Yes, that's correct. git branch -a will list them all. – Greg Hewgill – 2016-03-26T01:06:58.550

10Is a "git push" also a "git fetch" (in the other direction) followed by a "git merge"? – Ellen Spertus – 2011-03-16T23:51:52.903

114@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 – 2011-03-17T00:41:04.663

I saw the same answer in Quora :) Here : https://www.quora.com/Whats-the-difference-between-git-pulland-git-fetch.

– Pragyaditya Das – 2016-04-02T05:27:31.877

If you work with a bad internet connection, it may be a good idea to run a cron job to git fetch. – noɥʇʎԀʎzɐɹƆ – 2016-10-10T22:35:11.900

Somewhat vague explanations, even in git's ref docs. Docs say "git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch." Sounds like a nightmare if ALL fetched are merged into current branch. – Josef.B – 2016-12-15T02:54:02.480

31If I am at /home/alice/ and do git fetch /home/bob, what parameters should I pass to the subsequent git merge ? – ripper234 – 2011-05-27T19:38:02.027

I did a fetch and I couldn't commit my changes. Only after I pulled git allowed me to commit, why is that? – MushyPeas – 2017-06-19T06:43:26.303

@MushyPeas If you have a new question, please use the ask a question button.

– Greg Hewgill – 2017-06-19T06:49:04.923

Git fetch means you are get new repository from git which is created by someone.
Git pull means you are getting new code from the git or some of the repository which is pushed by some one.
– Chirag Prajapati – 2017-11-20T18:27:17.413

@GregHewgill, I had made some git sync on my local repository, after a long time I had committed my changes. I am seeing many commits on my recent commit(In each commit, I have seen a merge to dev branch commit message) By seeing that message I got a doubt that git sync after changing conflicts is considered as a commit or any concept so I had missed. – kvk30 – 2017-12-29T15:35:54.803

git pull use for getting updated merged code from repository. git fetch is for getting branches in the repository to exchange branch into a new branch. – Hasib Kamal – 2018-03-19T05:10:31.390

@GregHewgill If fetch only downloads changes from the remote branch and updates the repository data, but leaves the local branch unchanged, what is the point of fetching if the working directory will not show/reflect the changes? My question originally was that how could I see the changes someone else has done and then decide whether I would like to merge them into my working directory (i.e. experiment with other people's changes to make sure it does not break my work) but I am still confused how to do that. Should I just pul and experiment/explore, and if it was problematic, do a hard reset? – Joshua – 2018-06-09T17:02:37.020

1@Joshua: After fetching, the remote branches are available with names like origin/master (instead of just master, which is yours). You can view those branches locally to see what's changed before actually merging. – Greg Hewgill – 2018-06-09T23:18:58.043

is git push also a combination of git fetch + git merge, only that the remote repo is making that against the local repo – Honey – 2018-08-09T02:06:57.760

@Honey: No, git push never does a merge operation. It's completely unrelated to merging. – Greg Hewgill – 2018-08-09T02:12:43.967

Then how do things get updated? What command does that? How is it different from git merge? – Honey – 2018-08-09T08:26:01.410

1@Honey: You are expected to merge in your local repository before using git push. If you have further questions about how to use Git, please use the "Ask Question" button to ask a new question rather than asking in the comments here. Thanks! – Greg Hewgill – 2018-08-09T08:48:55.480

@GregHewgill: How come git fetch will update remote branch? 'fetch' means getting something from a source. If I use git fetch from my local branch, how can it update the remote git branch? – Anish Mittal – 2018-10-07T07:26:38.480

@AnishMittal: Please see Git: What is a tracking branch?

– Greg Hewgill – 2018-10-07T09:15:10.857

9Why specifically don't you recommend something like a cron job that does a "git fetch" automatically for you? No bad side effects come to mind, and it'd be nice to have my remote branches updated without having to think about it. – Bryan Henry – 2011-10-27T02:05:30.390

9@Sbrocket: I don't like surprises, especially not while working with my source control system. Changing branches from under me (even just remote branches) while working could be disorienting. – Greg Hewgill – 2011-10-27T18:29:26.257

1 921

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

Mouna Cheikhna

Posted 2008-11-15T09:51:09.660

Reputation: 29 570

29Agreed, 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 – 2013-05-13T18:44:23.410

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 – 2013-06-05T19:15:45.310

98@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 – 2013-07-17T06:48:09.527

18@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 – 2013-09-12T21:49:41.623

9When 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 - how do I see what was brought from the remote and how do I merge it into my local branches? – アレックス – 2014-06-13T01:40:52.943

8@Tino What I still don't understand is... what's the point? Why use fetch if it only updates .git? What is the intended benefit and what am I supposed to do after that? – BadHorsie – 2016-03-23T12:19:54.867

@BadHorsie git fetch downloads the changesets. – Tino – 2016-03-30T13:40:00.520

1git pull --ff-only is usually what I want. Does the mindless stuff automatically, asks before making history complicated. – Nick T – 2017-12-18T22:05:51.263

2I find this answer great. For me a good combination to achieve the goal from git fetch is typing 'git status' and you will see something like : "nothing to commit, working tree clean" then you can type 'git fetch' and then type 'git status' and you will see that your branch is "ahead of the remote repository" or smth like that. If you type "git pull" you will merge the branch but with 'git fetch' you only make conscious your local repository if you are ahead or behind with some commits. – eduardo92 – 2018-06-12T13:39:55.707

git pull means "fetch remote branches and merge my current branch with whatever random commits have been done in remote branches". That pretty much never makes any sense. git fetch followed by gitk or git log --oneline --graph --decorate --date-order and the maybe git rebase or git merge makes much more sense. – Mikko Rantalainen – 2018-10-25T10:50:31.523

1 068

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.


Posted 2008-11-15T09:51:09.660

Reputation: 10 965


Technically, the local and remote repositories are really one and the same. In Git, a repository is a DAG 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 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 – 2013-08-14T09:51:05.563

10Thanks much for the explanation. I didn't really understand until now that Git was designed so you didn't have to have a central repository. Everyone always says "DVCS" when describing Git, but as a relatively new programmer, that means nothing to me. I've never seen a CVCS, and I've also never not worked with a cental remote repository when collaborating with others (i.e. Github), so until now I've yet to understand what made Git special. – Brian Peterson – 2013-08-15T02:17:04.353

4So, based on this, why ISN'T it a good idea to git-fetch with a cron job? Always keeping a copy of the remote you're working with on your local machine seems like a good idea. In fact, I feel like writing a script that checks to see if I've updated my remote in the past 24 hours and linking it up with a udev hook for internet connection. – Brian Peterson – 2013-08-15T02:23:38.860

Silly question - Are these "three copies" maintained by Git and I never see it? or I have downloaded one copy and created two branches? – Nabheet – 2013-09-14T12:47:34.410

1@Nabheet: I believe the additional copies are not stored as ordinary files on your file system, but instead as alternate histories (changesets) inside your git repository files. – Keen – 2013-09-17T02:55:49.903

15One reason why it ISN'T a good idea to have a cron job: often when working on either a new ticket, or on updates to a branch, I like to see the changes being fetched. If the changes don't come in during a fetch, I'll be more confident in asking my fellow programmer 'hey did you push?'. I also get a sense of how much 'churn' in the repository since I last fetched. This also help to give me sense of the amount and speed of changes currently being made to this repository. – Michael Durrant – 2014-07-23T11:47:01.173

2@Nabheet Thing is that, Git is content-oriented. It stores data only once, and points to it multiple times. That's why in Git, even multiple commits on top of an original don't affect the size of the repo much, since most of the objects are the same. – cst1992 – 2016-11-05T09:43:18.407

1@cst1992: Yes. I didn't even remember asking this. I have learned quite a bit about Git in the past 3 years. :-) – Nabheet – 2016-11-07T19:01:35.310

@EmilLundberg "Git from the ground up" site has a broken link to the pdf file. You may want to update your comment to point to another location for the file. – CEGRD – 2016-11-19T19:28:12.597

this is the most clarifying answer. I like to keep it simple but I would just add some technical names in parenthesis like Head, index and working tree/dir along with the simple explanations/analogies (e.g. where I keep my own code) – Luis Martins – 2018-02-24T02:52:10.807

Please clarify: "git pull says "bring the changes in the remote repository where I keep my own code." bring them from XXX to YYY? – user949300 – 2018-03-11T23:08:18.580

I have a small typo there. So git pull first brings my local copy of the remote repository up to date just like git fetch, then it merges those changes into my local repository where I have my own code.

Imagine I have made some local commits, and someone else has made commits and pushed it to a remote repository.

At first, I know nothing about the commits the other person made. When I execute git fetch, I get a copy of the other person's work stored locally. Now I can compare it to mine. When I execute git pull I can merge their changes with my changes in my local workspace. – MikeD – 2018-03-14T18:52:08.297

@MikeD >> Git was designed to support a more distributed model with no need for a central repository. Read - to support people still committing often during long flights (during which there is no Internet). – haelix – 2018-09-06T18:23:04.480

This answer should be combined with the next down by Contango containing the image of the relationship. Then appended to the top answer, by Greg Hewgill, that gives the briefest and clearest explanation of the consequences of pull vs fetch. The order of the answers so far though is, fortunately, effectively that. – GG2 – 2018-10-01T18:06:41.077


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


Posted 2008-11-15T09:51:09.660

Reputation: 39 565

112An updated image with git clone and git merge would be very helpful! – MEMark – 2015-09-08T14:23:51.823

16Yes, 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 – 2015-10-21T19:57:33.403

9A 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 – 2015-11-25T00:27:05.997

9@Contango please add clone and merge. Would be helpful for newbies like me. – rents – 2016-01-15T16:02:32.247

9There are two diagrams showing clone and merge in other answers (below) by th3sly and thedarkpassenger. – intotecho – 2016-08-12T00:42:46.950


Does rebase come from the remote repository? I think that rebase is an operation over the local repository: https://git-scm.com/docs/git-rebase

– Edward Ross – 2016-09-26T09:55:26.350

2Rebase works on your local repository. The confusion is that the most common use case is to rebase your work on top of something that "came from" a remote repository. – MikeD – 2017-06-20T20:02:30.263

2This 'pull or rebase' is wrong. Because when you pull, you actually perform a fetch and than a merge. When you fetch, you get new changes from the remote branch to your local branch, but, and that's the important part, it's not added to your files yet. It's like the changes are parked away at some place. The changes will be added to your files, if you merge them. Than you changes are 'melted' to your files and committed. – AndaluZ – 2017-09-13T09:36:37.893

1Agree with @EdwardRoss, @MikeD and @AndaluZ: Rebase is a local repo to working copy operation. IMEHO, I'd change this so that Pull is remote repo to both local repo and working copy; Fetch is remote repo to local repo, and both Merge and Rebase are local repo to working copy. Part of the confusion ensues because git rebase is like git checkout, it's one command that has several different effects. e.g. git checkout can have the effect of either svn switch or svn revert (and others) depending on how it's used. – dgnuff – 2018-03-27T20:10:20.310

1@Contango - please update! – Vikas Goel – 2018-07-23T19:13:14.543


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


Posted 2008-11-15T09:51:09.660

Reputation: 4 395

6why not git diff ..origin? – Erik Allik – 2012-02-12T23:47:33.563

3git diff origin and git diff ..origin seem to work but not this weird ... stuff – Marc – 2013-01-08T19:32:06.003


@Compustretch There was not supposed to be a space. git diff ...origin is equivalent to git diff $(git-merge-base HEAD origin) origin (see the git diff [--options] &lt;commit&gt;...&lt;commit&gt; [--] [&lt;path&gt;…] section of https://www.kernel.org/pub/software/scm/git/docs/git-diff.html#_description), which is different from git diff origin; git diff ...origin is conceptually the changes made in origin since the current branch branched from origin, while git diff origin includes also the reverse of the changes made in the current branch since it branched from origin.

– Max Nanasy – 2013-08-01T19:34:28.987

1none of the .. commands worked for me (on Windows), but git diff origin/master works, as mentioned below – Brian Burns – 2014-02-20T09:07:13.560

11Great addition! I was confused by the dots, isn't it: git diff origin – harm – 2010-07-27T12:15:09.147

same here using git 2.0.0 on OSX. None of these commands worked. Have they been deprecated? – K.-Michael Aye – 2014-06-26T02:39:14.750


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.


Posted 2008-11-15T09:51:09.660

Reputation: 4 408

9origin/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 – 2013-05-28T16:00:14.867

1Still confusing. I thought git fetch was to literally download changes on the remote repo into your local repo, but NOT commit them - ie, they still need to be added/committed to your local repo. – krb686 – 2015-02-26T14:57:50.663

2fetch only pulls from remote/origin (github) to your local origin. But it doesn't merge it to your actual working files. if you do a pull it will fetch and the merge to your current working files – Gerardo – 2015-02-26T19:45:36.133


Sometimes a visual representation helps.

enter image description here


Posted 2008-11-15T09:51:09.660

Reputation: 3 671



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/


Posted 2008-11-15T09:51:09.660

Reputation: 36 593

1Sounds to me like if someone just wants the local code to reflect "the tip", they should use git clone. I put the tip in quotes, as I assume it would mean whatever master is and what someone would "Download as zip" from github.com – Chris K – 2013-09-12T08:27:15.393

2what if you're not happy with the changes after you git fetch? what to do next? – Kugutsumen – 2015-03-24T06:06:37.177

Your paragraph on rebase was just what I was looking for. The whole idea about zeroing out of everything, updating from remote, then replaying your changes on top of previous commits that happened while you were working. Perfect explanation assuming it's correct. ;) – coblr – 2016-03-03T00:01:20.700


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

Posted 2008-11-15T09:51:09.660

Reputation: 201 577

4Very interesting, but I can't really see a use case where you want "just the code". Et what happen with your code when you fetch? Is it erased? What happen whith the remote changes? How does it goes into your repo whithout erasing your code if you don't merge? – e-satis – 2010-03-27T16:21:55.710

A simple use case for the fetch command: perform time consuming operations involving other people's recent commits, such as a merge or a code review, accessing only your up-to-date local repository without network connectivity requirements, because you previously used fetch to download everything you need quickly (e.g. while you are visiting some other developer and connected to some other repository's network). The pull command would download the same commits, but the merging it performs can be undesirable. – Lorenzo Gatti – 2013-09-19T10:25:33.023

10@e-satis: The remote branch is also stored locally on your machine. So when you do git fetch it fetches changes from the repository and updates your local remote branch. It does not affect your local branch which tracks the local remote branch, so does not affect your working copy. Now, when you do a merge it will merge the fetched changes with your local branch. – jeffreyveon – 2011-10-31T04:23:36.440


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

Antonio Bardazzi

Posted 2008-11-15T09:51:09.660

Reputation: 2 081

33You 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 – 2012-08-31T20:02:48.197


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.


Posted 2008-11-15T09:51:09.660

Reputation: 2 463

2@JustinOhms If git pull --rebase is not the right thing in the given situation, is it right if it is done in two steps? If it is the right thing to do, what is extra the benefit to doing it in two steps? – Kaz – 2013-05-23T21:56:38.800

@Kaz - because the rebase is not automatic. Fetching the changes first allows you to make the judgement call. It doesn't fix the problem with rebasing history you've already pushed. It will allow you to see if it is safe to rebase changes you have not already pushed. – Justin Ohms – 2013-05-24T21:11:52.533

2@JustinOhms How would you decide whether it is safe to rebase changes? I would just try git rebase, and backtrack if it made a mess, in which case I might as well do git pull --rebase. But maybe you have some other way? – Kaz – 2013-05-25T06:14:19.450

1@KaZ gitk allows you to see the branch structure visually. It will show your the position of your local head, remotes, and your branch structures in relation to what you have fetched. This way you can ensure that you are not rebasing fetched changes that are based on an ancestor that is prior to what you have already pushed to your remote(s). – Justin Ohms – 2013-05-28T19:18:02.403

Use rebase when you are working on a local branch not already pushed. If you are working on a branch that exists in the remote, rebase can result in some nasty issues so you should prefer a regular merge. – Justus Romijn – 2014-12-01T08:39:57.337


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


Posted 2008-11-15T09:51:09.660

Reputation: 1 376

14People, 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. – María Luisa Carrión Donderis – 2016-10-04T00:41:48.803


OK, here are 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


Posted 2008-11-15T09:51:09.660

Reputation: 43 514



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

Sazzad Hissain Khan

Posted 2008-11-15T09:51:09.660

Reputation: 14 113


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

Posted 2008-11-15T09:51:09.660

Reputation: 11 013

Doesn't a git pull also perform a merge, i.e. going all the way to the working copy? – Kamiel Wanrooij – 2014-03-24T17:28:47.543

Good point, yes it will put all the changes in your working copy, and then you can commit it yourself into the local repo. I will update the visual. – Justus Romijn – 2014-03-25T07:50:20.033

@JustusRomijn Doesn't a pull also update the local repository? Shouldn't there be an asterisk between the origin and working copy asterisks? – user764754 – 2015-01-08T09:34:07.497

1@user764754 When you pull, your working copy get the changes (there can also be some conflicts which you might need to resolve). You still have to commit it into your local repository. – Justus Romijn – 2015-01-12T07:17:24.070

@JustusRomijn:Thanks for the illustration.It would be great if you can make the diagram more comprehensive by illustrating the effects of operations such as reset ,cherry pick on the repository states. – jith912 – 2015-01-17T12:42:39.253

@jith912 I think it would be a bit outside of the scope of this question topic, but I might create such one and put it on a blog. If I do, I will add the link here for reference. – Justus Romijn – 2015-01-19T08:11:42.393

@jith912 in one of the answers this link is provided: http://ndpsoftware.com/git-cheatsheet.html

– Justus Romijn – 2015-02-13T10:35:37.610


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.

pn1 dude

Posted 2008-11-15T09:51:09.660

Reputation: 2 850

21Unfortunately, I have no idea what this diagram is supposed to show... – BadHorsie – 2016-03-23T12:16:28.113

Not that hard to read: the boxes represent the status of a repo, that in each row changes in time left-to-right after the reported operation in row 2 of the box. The labels R0n are tags in git, and a tag with a + is yet uncommited stuff. Sanbox is used for your working folder, which is different from the repo folder, where commited stuff is stored. – user1708042 – 2017-08-30T07:57:02.063


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)

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

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

Posted 2008-11-15T09:51:09.660

Reputation: 1 009


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.


Posted 2008-11-15T09:51:09.660

Reputation: 4 940

2I'd rather say git pull == git fetch + git merge :) – melvynkim – 2013-06-07T10:38:29.667

1But git pull --rebase = git fetch + git rebase – Tino – 2013-07-17T07:06:50.300


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

Posted 2008-11-15T09:51:09.660

Reputation: 57 996


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.


Posted 2008-11-15T09:51:09.660

Reputation: 979


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

Posted 2008-11-15T09:51:09.660

Reputation: 1 752


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

Rohitashv Singhal

Posted 2008-11-15T09:51:09.660

Reputation: 2 827

And neither help if git thinks you are behind by commits and can "fast-forward", which upon I ended up rm -rfing the whole thing and starting over. Stupid Git, please just let me get current so I can go back to work? – Chris K – 2013-09-11T22:01:21.250


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) [email protected] >> remote/origin/[email protected]

  2. Integrating new commits to local branch

    (inside-repo operation) remote/origin/[email protected] >> [email protected]

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

Posted 2008-11-15T09:51:09.660

Reputation: 2 680


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.


Posted 2008-11-15T09:51:09.660

Reputation: 18 118


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

Posted 2008-11-15T09:51:09.660

Reputation: 3 026


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


Posted 2008-11-15T09:51:09.660

Reputation: 5 788

Guys, I still don't understand it. So can we skip git fetch and use git pull directly? The reason is that git pull already includes git fetch. – None – 2015-04-07T17:13:48.680


Trying to be clear and simple.

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.


Posted 2008-11-15T09:51:09.660

Reputation: 3 099


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.


Posted 2008-11-15T09:51:09.660

Reputation: 361


git pull = git fetch + git merge 

Saqib R.

Posted 2008-11-15T09:51:09.660

Reputation: 2 034


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 ibn Mohammed

Posted 2008-11-15T09:51:09.660

Reputation: 6 869


From Pro Git § 2.5 Git Basics - Working with Remotes: Fetching and Pulling from Your Remotes:

It’s important to note that the fetch command pulls the data to your local repository — it doesn’t automatically merge it with any of your work or modify what you’re currently working on. You have to merge it manually into your work when you’re ready.

If you have a branch set up to track a remote branch, you can use the git pull command to automatically fetch and then merge a remote branch into your current branch. This may be an easier or more comfortable workflow for you; and by default, the git clone command automatically sets up your local master branch to track the remote master branch on the server you cloned from (assuming the remote has a master branch). Running git pull generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you’re currently working on.

Zhenxiao Hao

Posted 2008-11-15T09:51:09.660

Reputation: 3 830


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

Animesh Sharma

Posted 2008-11-15T09:51:09.660

Reputation: 2 045


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.


Posted 2008-11-15T09:51:09.660

Reputation: 2 135


From git cheat sheet:

git fetch <remote> // Download all changes from <remote>, but don't integrate into HEAD
git pull <remote> <branch> // Download changes and directly merge/integrate into HEAD

Nan Xiao

Posted 2008-11-15T09:51:09.660

Reputation: 7 485


From what I understood,

Git pull - Pulls down from a specified remote (Specified by the user) and will instantly merge it into a branch we are presently on. It is basically a mix of Fetch and Merge commands.

Git Fetch - It is same as Pull, but it won't do any merging. So you can carefully monitor the files before merging it.

This url must be of help for further understanding : The difference between git pull, git fetch and git clone (and git rebase).

Pragyaditya Das

Posted 2008-11-15T09:51:09.660

Reputation: 757


In short and simple terms:

git fetch: Look if there is new stuff.

git pull: Take the new stuff and put it on top of your stuff.


Posted 2008-11-15T09:51:09.660

Reputation: 1 712


I believe most of the answers answered the difference quite well. I would emphasise on when to use which instead.

Enter image description here

Fetch can be useful when you need to get the update of other developers, yet want to continue your work unhampered. People who often want to go offline and work uses fetch to get latest update till she/he was online. Later when she/he is comfortable with her changes, merges the ones from the branch into his/her workspace.

Whereas people who are working online and are very sure of their changes and want to get the latest code and merge straight away uses pull. I rarely use fetch because to check for the latest updates I check them via the GitHub website and I always work offline. As I mentioned you might have use for the above scenario.


Posted 2008-11-15T09:51:09.660

Reputation: 4 175


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

Posted 2008-11-15T09:51:09.660

Reputation: 1 894


Git fetch syncs the catalog of the remote repository to your local. It will not merge the file/code changes from remote to your local branch.

Git pull downloads the changes related to your current local branch and then merge it.

Arnel Lenteria

Posted 2008-11-15T09:51:09.660

Reputation: 35