Categories
git git-fetch git-pull version-control

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

13280

What are the differences between git pull and git fetch?

7

  • 417

    I found this well written article about git fetch and git pull it’s worth the reading: longair.net/blog/2009/04/16/git-fetch-and-merge

    Sep 16, 2010 at 6:57

  • 64

    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 !

    May 4, 2014 at 14:32


  • 36

    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…

    Dec 9, 2014 at 20:09

  • 47

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

    Jun 29, 2015 at 10:15


  • 1

    git pull pulls from a remote branch and merges it. git fetch only fetches from the remote branch but it does not merge

    Dec 29, 2021 at 18:11

11076

In the simplest terms, git pull does a git fetch followed by a git merge.


git fetch updates your remote-tracking branches under refs/remotes/<remote>/. This operation is safe to run at any time since it never changes any of your local branches under refs/heads.

git pull brings 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.

10

  • 373

    “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

    Nov 10, 2009 at 12:13

  • 220

    @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 6, 2010 at 10:10

  • 139

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

    Mar 17, 2011 at 0:41

  • 39

    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, 2011 at 19:38


  • 119

    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.

    Sep 28, 2012 at 16:23

2479

  • git pull tries to automatically merge after fetching commits. It is context sensitive, so all pulled commits will be merged into your currently active branch. git 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.

  • git fetch gathers any commits from the target branch that do not exist in the 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 git merge afterwards.

7

  • 40

    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, 2013 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 5, 2013 at 19:15

  • 148

    @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, 2013 at 6: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, 2013 at 21:49

  • So, fetch command is something like a “commit from the remote to local”. Right?

    Aug 12, 2021 at 20:44

1355

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.

2

  • 87

    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.

    Aug 14, 2013 at 9:51

  • Wrong. A repository doesn’t contain a copy of your working tree. A repository is a list of changes. So there is only a single instance of a project on a workstation unless you explicitly cp -R it.

    – Aleks N.

    Jun 20 at 7:32