Git pull vs fetch: What's the difference?
Difference between Git fetch and pull
The key difference between git fetch and pull is that git pull copies changes from a remote repository directly into your working directory, while git fetch does not. The git fetch command only copies changes into your local Git repo. The git pull command does both.
To really understand the difference between pull and fetch, you must know how a Git installation is structured.
On a user’s workstation, a Git installation includes the following items:
- The local Git repository where the history of all commits across all branches are maintained.
- A working directory where a developer actively edits and updates files that Git tracks.
Benefits of the git pull command
If a developer finds out that there are new, updated files on a remote repository like GitHub, they will likely want to copy those changes from GitHub to both their local repository and into their working directory.
This is what the git pull command does. The git pull command updates both the user’s local Git repository and the files in their working directory.
That provides the developer with two benefits:
- The local Git repo is now in sync with the remote repo.
- The local filesystem has the latest, most up to date files.
The git pull command has one prerequisite: the user cannot be actively editing any tracked files in their local workspace that conflict with what’s on the remote server.
If Git notices any conflicting files in the user’s workspace, it aborts the task of updating the user’s workspace and only updates the user’s local Git repo.
Benefits of the git fetch command
If you are actively working on files tracked by Git, but you still want to update your local repository with the latest changes from a remote repository, use the git fetch command.
A git fetch updates your local repo with all of the latest changes from a remote repo but doesn’t make any changes to your local workspace.
The benefit of the git fetch vs git pull is that a fetch enables you to continue editing files in your local working directory without having to merge your code with updates from the remote repo.
With a git fetch, you can finish editing files locally, commit your files and then do a git merge to synchronize your updates with the fetched files. This brings you up to date with the updates the fetch pulled down from the remote machine.
Ahead or behind?
One of the other benefits of a git fetch is that it allows you to find out if the branch you are working on is ahead or behind the branch on the server.
In the following example, a git status command informs us that we are up to date with the origin/master branch on the server.
However, when we perform a git fetch, we are informed that we are actually three commits behind the master Git branch on the server.
If you want to know how far ahead or behind your local branch is compared to what is on the server, the git fetch command, along with a git status, allows you to know that.
An aborted git pull is a fetch
If you try to do a git pull operation, but your working directory has uncommitted files, or a copy of the remote files into your workspace would create a merge conflict, the git pull operation short-circuits and turns into a git fetch operation instead. All of the updates from the remote repository are copied into your local Git repository, but the system leaves your local workspace alone.
This emphasizes the fact that the git pull is really two operations combined into one: the git fetch and the git merge commands. If a developer successfully issues a git fetch and a git merge command right after one another, the result is equivalent to a git pull.
Should I use git fetch or git pull?
If your workspace has no uncommitted files, and you want to copy the latest changes from a remote repository directly into your working directory, then issue the git pull command.
If you want to pull down the latest changes from a remote repository without overwriting anything in your working directory, then use git fetch, and then do a git merge when the time is right.