git fetch vs git pull: Differences, Examples and When to Use Each

git fetch and git pull both get changes from GitHub, but they do very different things to your work. This lesson explains the difference with examples, shows how to review changes before integrating them, and helps you choose between merge and rebase when pulling.

---

⚖️ The Short Answer

• git fetch downloads new commits and branches from the remote without changing your files or your current branch. It only updates remote-tracking branches such as origin/main.
• git pull does a fetch and then integrates the new commits into your current branch (with a merge by default, or a rebase).

git pull  =  git fetch  +  git merge   (or git rebase with --rebase)

---

🧭 Side-by-Side Comparison

	git fetch	git pull
Downloads new commits	✅	✅
Updates origin/main and other remote-tracking branches	✅	✅
Changes your current branch	❌	✅
Changes files in your working directory	❌	✅
Can cause merge conflicts	❌	✅
Safe to run any time	✅ Always	⚠️ Commit or stash your work first
Best for	Seeing what changed before integrating	Quickly updating your branch

---

🔍 git fetch in Practice

git fetch                 # fetch from origin
git fetch --all           # fetch from every remote
git fetch --prune         # also remove remote-tracking branches deleted on GitHub
git fetch upstream        # fetch from another remote, e.g. the original project of a fork

After fetching, inspect the incoming changes before they touch your work:

git status
# Your branch is behind 'origin/main' by 3 commits, and can be fast-forwarded.

git log --oneline main..origin/main     # commits on GitHub that you do not have
git log --oneline origin/main..main     # your commits that GitHub does not have
git diff main origin/main               # the actual changes

Then integrate when you are ready:

git merge origin/main      # or: git rebase origin/main

---

📥 git pull in Practice

git pull                   # fetch + merge the upstream of the current branch
git pull origin main       # fetch main from origin and merge it into the current branch
git pull --rebase          # fetch + rebase your local commits on top
git pull --ff-only        # only update if no merge is needed; otherwise stop

Merge or rebase when pulling?

Strategy	Command or setting	Result when both sides have new commits
Merge (default)	git config --global pull.rebase false	A merge commit joins the two histories
Rebase	git config --global pull.rebase true	Your local commits are replayed on top; history stays linear
Fast-forward only	git config --global pull.ff only	Pull refuses and you decide what to do

If neither is configured, recent Git versions show a hint asking you to choose; that is why the config lesson sets pull.rebase false. Many teams prefer --rebase for feature branches to avoid “Merge branch ‘main’ of github.com…” commits. See rebase vs merge.

---

🧪 A Safe Workflow Before Pushing

git status                     # 1. make sure your work is committed (or stashed)
git fetch                      # 2. see what changed on GitHub
git log --oneline main..origin/main
git pull --rebase              # 3. integrate (resolve conflicts if needed)
npx playwright test            # 4. run your tests on the combined code
git push                       # 5. share

Unfinished work? Save it temporarily with git stash before pulling.

---

🐞 Common Situations

Message	Meaning and fix
“Your branch is behind ‘origin/main’ by 3 commits, and can be fast-forwarded”	Only GitHub has new commits; git pull will fast-forward cleanly
“Your branch and ‘origin/main’ have diverged”	Both sides have new commits; pull with merge or rebase
“Your local changes would be overwritten by merge”	Commit or stash your changes, then pull
“Automatic merge failed; fix conflicts”	Resolve the merge conflicts, then commit
Deleted remote branches still listed	git fetch --prune (or set fetch.prune true)

---

📝 Assignment

Use two clones of the same GitHub repository (practice and practice-copy):

1. Commit and push a change from practice-copy.
2. In practice, run git fetch and git status. Confirm your files did not change.
3. Use git log main..origin/main and git diff main origin/main to inspect the incoming change, then git merge origin/main.
4. Create diverging commits in both clones and pull once with merge and once with --rebase. Compare the histories with git log --oneline --graph.
5. Delete a branch on GitHub and remove its remote-tracking branch with git fetch --prune.

---

❓ FAQ

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

git fetch only downloads new commits and updates remote-tracking branches. git pull downloads them and also merges (or rebases) them into your current branch.

🤔 Is git fetch safe?

Yes. It never changes your working files or your current branch, so it is always safe to run.

🤔 When should I use git pull –rebase?

When you want a linear history without extra merge commits, for example on your own feature branch. Avoid rebasing commits others have already based work on.

🤔 How do I see what changes will come with git pull?

Run git fetch, then git log main..origin/main for the commits and git diff main origin/main for the changes.

🤔 How do I fix “Your branch and origin/main have diverged”?

Run git pull (merge) or git pull --rebase, resolve any conflicts, then push.

---

🎯 Next Steps

• 🚀 Push an Existing Project to GitHub
• 🌿 Git Branches: Create, Switch, Rename and Delete
• 📘 Git and GitHub Tutorial: full course