What is the difference between git fetch and git pull?
Understand the difference between git fetch and git pull, why fetch is safer for shared branches, and when to use pull --rebase in your Git workflow.
Expected Interview Answer
git fetch downloads new commits and branches from a remote into your local copy of that remote without touching your working files, while git pull does the same fetch and then immediately merges (or rebases) those commits into your current branch.
Fetch is the safe, read-only step: it updates remote-tracking refs like origin/main so you can inspect incoming changes before doing anything to your own branch. Pull is fetch plus an automatic merge (or, with --rebase, a rebase), which updates your working directory right away. Many teams prefer fetch-then-review-then-merge for shared branches, and reserve pull for quick, low-risk updates on their own feature branches.
- Fetch lets you inspect changes before merging
- Pull saves a step for routine updates
- Understanding both avoids surprise merge conflicts
- Supports safer collaboration on shared branches
- Foundation for understanding rebase workflows
AI Mentor Explanation
Git fetch is like a scout watching the opposition's net practice and reporting back what deliveries they are bowling, without the team changing its own batting order yet. Git pull is the captain taking that report and immediately reshuffling the batting line-up to match. Fetch informs; pull commits the team to react right away, which is riskier mid-innings.
Step-by-Step Explanation
Step 1
Run git fetch
Downloads new commits, branches, and tags from the remote and updates remote-tracking refs like origin/main only.
Step 2
Inspect the update
Use git log origin/main or git diff main origin/main to see what changed before touching your branch.
Step 3
Decide how to integrate
Choose git merge origin/main or git rebase origin/main once you have reviewed the incoming commits.
Step 4
Run git pull instead
git pull performs the fetch and then automatically merges (or rebases with --rebase) into your current branch in one step.
Step 5
Resolve any conflicts
Whether via pull or a manual merge after fetch, resolve conflicts, then commit or continue the rebase.
What Interviewer Expects
- Explains fetch as read-only and pull as fetch plus merge/rebase
- Knows remote-tracking branches like origin/main
- Can describe when to prefer fetch-then-review over pull
- Mentions git pull --rebase as an alternative to a merge commit
- Understands the risk of surprise conflicts with pull on shared branches
Common Mistakes
- Assuming git fetch changes your working directory files
- Using git pull blindly on shared branches without reviewing changes
- Confusing origin/main (remote-tracking branch) with local main
- Forgetting that pull can create unwanted merge commits
Best Answer (HR Friendly)
“Git fetch checks a shared online folder for new updates without changing anything on your computer yet, so you can look before you leap. Git pull does that same check but immediately blends the updates into your current work, which is quicker but riskier if you have not reviewed what changed.”
Code Example
# Safe: fetch only, nothing local changes
git fetch origin
git log main..origin/main --oneline # preview incoming commits
git merge origin/main # merge only after reviewing
# Faster but immediate: fetch + merge in one step
git pull origin main
# Fetch + rebase instead of a merge commit
git pull --rebase origin mainFollow-up Questions
- What does origin/main mean as a remote-tracking branch?
- When would you use git pull --rebase instead of a plain git pull?
- How do you undo a git pull that created conflicts?
- What is the difference between git fetch --all and fetching one remote?
- How does git pull behave differently on a diverged branch?
MCQ Practice
1. What does git fetch update?
git fetch only updates local remote-tracking refs such as origin/main; it never touches your working directory or current branch.
2. What extra step does git pull perform beyond git fetch?
git pull runs a fetch and then automatically merges (or rebases with --rebase) the new commits into your current branch.
3. Why might a team prefer fetch-then-merge over a plain pull on a shared branch?
Fetching first lets you inspect incoming commits with log or diff before deciding how, or whether, to integrate them.
Flash Cards
What does git fetch change locally? — Only remote-tracking refs like origin/main; your working directory and current branch stay untouched.
What is git pull equivalent to? — git fetch followed by git merge (or git rebase with --rebase) into your current branch.
Why use fetch instead of pull on shared branches? — It lets you review incoming commits before merging, avoiding surprise conflicts.
What does git pull --rebase do differently? — It replays your local commits on top of the fetched commits instead of creating a merge commit.