Moderator Note: Given that this question has already had sixty-four answers posted to it, consider whether or not you are contributing anything new before posting another one.
What are the differences between
git pull and
In the simplest terms,
git pull does a
git fetch followed by a
You can do a
git fetch at any time to update your remote-tracking branches under
This operation never changes any of your own local branches under
refs/heads, and is safe to do without changing your working copy. I have even heard of people running
git fetch periodically in a cron job in the background (although I wouldn't recommend doing this).
git pull is what you would do to bring a local branch up-to-date with its remote version, while also updating your other remote-tracking branches.
Git documentation: git pull
git-pull - Fetch from and merge with another repository or a local branch SYNOPSIS git pull … DESCRIPTION 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.
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
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
git checkout master git fetch git diff origin/master git rebase origin master
The short and easy answer is that
git pull is simply
git fetch followed by
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
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.
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.
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
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
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:
git fetchit 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.
git pull, it will do basically fetch (as explained previously) and merge any new changes to your master branch and move the pointer to
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.
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.
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.
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 where I keep my own code."
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.
git fetch is similar to
pull but doesn't merge. i.e. it fetches remote updates (
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.
git branch -a will show you exactly what’s going on with all your branches - local and remote.
This blog post was useful:
git clone and
I thought I'd update this to show how you'd actually use this in practice.
Update your local repo from the remote (but don't merge):
After downloading the updates, let's see the differences:
git diff master origin/master
If you're happy with those updates, then merge:
On step 2: For more on diffs between local and remotes, see: compare local git branch with 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.
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 ...
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/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.
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
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:
Copying new commits from remote branch to copy of this remote branch inside local repo.
Integrating new commits to local branch
There are two ways of doing step 2. You can:
git terminology, step 1 is
git fetch, step 2 is
git merge or
git pull is
git fetch and
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 . ===================================================== ================= . ================= =================== ============= REMOTE REPOSITORY . REMOTE REPOSITORY LOCAL REPOSITORY WORKING COPY (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:
It’s important to note that the
fetchcommand 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 pullcommand 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 clonecommand 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 pullgenerally fetches data from the server you originally cloned from and automatically tries to merge it into the code you’re currently working on.
Git obtains the branch of the latest version from the remote to the local using two commands:
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.
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.
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."
From what I understand, git pull will pull down from a remote whatever you ask (so, whatever trunk you’re asking for) and instantly merge it into the branch you’re in when you make the request. Pull is a high-level request that runs ‘fetch’ then a ‘merge’ by default, or a rebase with ‘–rebase’. You could do without it, it’s just a convenience.
%> git checkout localBranch %> git pull origin master %> git branch master * localBranch
The above will merge the remote “master” branch into the local “localBranch”.
Fetch is similar to pull, except it won’t do any merging.
%> git checkout localBranch %> git fetch origin remoteBranch %> git branch master * localBranch remoteBranch
So, the fetch will have pulled down the remoteBranch and put it into a local branch called “remoteBranch”. creates a local copy of a remote branch which you shouldn’t manipulate directly; instead create a proper local branch and work on that. ‘git checkout’ has a confusing feature though. If you ‘checkout’ a local copy of a remote branch, it creates a local copy and sets up a merge to it by default.
What is the difference between
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.
If there is sufficient interest, I suppose I could update the image to add
git clone and
git pull = git fetch + git merge
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 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
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.
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
fetch vs pull
fetch will download any changes from the remote branch, updating your repository data, but leaving your local branch unchanged.
pull will perform a fetch and additionally merge the changes into your local branch.
What's the difference? pull updates you local branch with changes from the pulled branch. A fetch does not advance your local branch.
Actually Git maintains a copy of your own code and the remote repository.
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.
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.
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.
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
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).
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.
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.
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.
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.
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.
Initial State of the two Branches when you forked the main project on your local repository will be like this- (
C are Modules already completed of the project)
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
F and modified
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.
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.
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
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.
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 code, but pull get the code changes and merge it your local branch, read on to get more details about each:
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.
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...
A simple Graphical Representation for Beginners,
will fetch code from repository and rebase with your local... in git pull there is possibility of new commits getting created.
but in ,
will fetch code from repository and we need to rebase it manually by using
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.
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
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
This command update your
branch with current
branch state. Let's continue with
GitFlow. Multiple feature
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
Documentation for GitFlow https://gist.github.com/peterdeweese/4251497
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.