How are "git fetch" and "git pull" different?

When you need to get changes that other team members have pushed to the remote repository, you have two commands to choose from: git fetch and git pull. They both download data from the remote, but they differ in what happens next.

Quick comparison

The short version: git fetch downloads changes and lets you decide what to do with them. git pull downloads and merges in one step.

How git fetch works

git fetch retrieves commits, branches, and tags from the remote without touching your local branches or working directory. It updates your remote-tracking branches (like origin/main) so you can see what's changed.

git fetch origin

After fetching, you can inspect the differences before merging:

# See what commits are on the remote that you don't have
git log HEAD..origin/main --oneline

# See the actual code changes
git diff HEAD origin/main

You can run git fetch as often as you like --- it won't break anything or create merge conflicts. It's purely a read operation on your local repository.

How git pull works

git pull is essentially a shortcut for running git fetch followed by git merge. It downloads the remote changes and immediately merges them into your current branch:

git pull origin main

This is convenient when you know you want the latest changes and expect a clean merge. Most developers run git pull at the start of the day or before starting work on a new feature.

The downside is that if there are conflicting changes, you'll need to resolve merge conflicts right away --- you don't get a chance to review the incoming changes first.

When to use fetch vs pull

Use git fetch when:

• You want to see what's changed on the remote before merging
• You're in the middle of work and don't want to deal with conflicts yet
• You're reviewing a colleague's branch before integrating it
• You want to compare branches (git diff main origin/main)

Use git pull when:

• You're starting fresh work and need the latest code
• You're on a branch that only you work on
• You're confident there won't be conflicts

Using fetch + merge as an alternative to pull

Instead of git pull, you can fetch and merge as separate steps. This gives you the same result but with a chance to inspect changes between the two steps:

git fetch origin
git log HEAD..origin/main --oneline   # review what's coming in
git merge origin/main                  # merge when ready

This workflow is especially useful on long-running feature branches where you want to understand what's changed on main before pulling it in.

Pull with rebase for cleaner history

By default, git pull creates a merge commit when your local branch has diverged from the remote. Over time, these merge commits clutter the log. You can use rebase instead to replay your local commits on top of the remote changes:

git pull --rebase origin main

This produces a linear history without merge commits. To make rebase the default for all pulls:

git config --global pull.rebase true

When to avoid rebase: if you've already pushed the commits you'd be rebasing, or if you're working on a shared branch where others depend on the exact commit hashes.

Related

• git fetch command reference
• git pull command reference
• git merge command reference
• git rebase command reference

DeployHQ automatically fetches the latest changes from your repository when deploying, so your production server always gets the right version. Try it free.