Git Notes
Learn how to use git pull to download and integrate remote changes. Understand pull strategies, pull with rebase, handling conflicts, and best practices.
Every time you sit down to code, the first question should be: "Has anyone else made changes since I last synced?" The git pull command answers that question and integrates those changes into your local branch in one step. It is probably the command you will run most frequently in team environments.
Under the hood, git pull is actually two operations combined: git fetch (download new data from the remote) followed by git merge (integrate that data into your current branch). Understanding this composition helps you troubleshoot problems and choose the right pull strategy for your workflow.
How Git Pull Works Internally
| Step 1 (fetch) | Download remote objects and update remote-tracking branches |
| Step 2 (merge) | Merge the remote-tracking branch into your current branch |
| Remote | [A]──[B]──[C]──[D]──[E] |
| Local | [A]──[B]──[C] (before pull) |
| Local | [A]──[B]──[C]──[D]──[E] (after pull, fast-forward) |
When your local branch has no commits that the remote does not have, Git performs a "fast-forward" — it simply moves your branch pointer forward. No merge commit needed.
Basic Pull Commands
# Pull from the tracked upstream (most common usage)
git pullremote: Enumerating objects: 8, done. remote: Counting objects: 100% (8/8), done. remote: Compressing objects: 100% (4/4), done. Unpacking objects: 100% (5/5), 893 bytes, done. From github.com:team/project a1b2c3d..f4e5d6c main -> origin/main Updating a1b2c3d..f4e5d6c Fast-forward src/api/routes.js | 35 ++++++++++++++++++++ src/models/user.js | 8 +++-- tests/api.test.js | 22 +++++++++++++ 3 files changed, 63 insertions(+), 2 deletions(-)
# Pull from a specific remote and branch
git pull origin main
git pull upstream develop
# Pull into a different branch than current (rare)
git pull origin main:local-mainPull with Rebase: The Clean Alternative
Standard pull creates merge commits when your branch and the remote have diverged. Pull with rebase replays your local commits on top of the remote changes instead:
git pull --rebase origin mainStandard pull (merge)
┌── [X] ── [Y] (your local commits)
[A]──[B]──┤ ──[M] (merge commit)
└── [C] ── [D] (remote commits) ─┘
Pull with rebase (linear)
[A]──[B]──[C]──[D]──[X']──[Y'] (your commits replayed on top)
The rebase approach produces a cleaner, linear history. Most professional teams prefer this for feature branches:
# Set rebase as default for all pulls
git config --global pull.rebase true
# Set rebase for a specific branch only
git config branch.feature/auth.rebase trueHandling Conflicts During Pull
When your changes and the remote changes touch the same lines:
git pull origin mainAuto-merging src/config.js CONFLICT (content): Merge conflict in src/config.js Automatic merge failed; fix conflicts and then commit the result.
Resolution workflow:
# 1. See which files have conflicts
git statusUnmerged paths:
(use "git add <file>..." to mark resolution)
both modified: src/config.js# 2. Open the file - conflict markers show both versions
cat src/config.js<<<<<<< HEAD const API_URL = "https://api.staging.example.com"; ======= const API_URL = "https://api.v2.example.com"; >>>>>>> origin/main
# 3. Edit the file to resolve (keep the correct version)
# 4. Stage the resolved file
git add src/config.js
# 5. Complete the merge
git commit -m "merge: resolve config URL conflict"
# Or if using pull --rebase:
git rebase --continueTo abort and go back to pre-pull state:
git merge --abort # For regular pull
git rebase --abort # For pull --rebasePull Options and Variants
# Fast-forward only - fail if merge is needed (safe for main)
git pull --ff-only origin main
# Pull without auto-committing (inspect before committing)
git pull --no-commit origin main
# Pull and squash remote commits into one
git pull --squash origin main
# Pull with autostash (stash uncommitted work, pull, then pop)
git pull --autostash origin main
# Verbose mode - see more detail
git pull --verbose origin mainPull vs Fetch: When to Use Each
| Scenario | Use Pull | Use Fetch |
|---|---|---|
| Quick update, trust the remote | ✅ | |
| Want to inspect changes first | ✅ | |
| On shared branch like main | ✅ (with --ff-only) | |
| Reviewing teammate's branch | ✅ then checkout | |
| Uncertain about conflicts | ✅ then merge manually |
The fetch-then-merge workflow gives you more control:
# Safer alternative to blind pull
git fetch origin
git log HEAD..origin/main --oneline # Preview what is coming
git diff HEAD..origin/main --stat # See file changes
git merge origin/main # Integrate when readyBest Practices for Pulling
- Always commit or stash before pulling — Pulling with dirty working directory can create confusing conflicts between your uncommitted work and incoming changes.
git stash # Save work in progress
git pull --rebase origin main # Get latest cleanly
git stash pop # Restore your work- Use --ff-only on protected branches — Prevents accidental merge commits on main.
- Pull frequently — Daily (or more) pulls catch conflicts early when they are small.
- Configure default pull behavior — Avoid different behaviors on different machines.
Common Mistakes
Mistake 1: Pulling with uncommitted changes. This can create merge conflicts between your work-in-progress and the incoming changes. Always commit or stash first.
Mistake 2: Not understanding whether pull uses merge or rebase. Check your configuration with git config pull.rebase to know what will happen.
Mistake 3: Pulling on the wrong branch. Running git pull origin main while on your feature branch merges main into your feature, which may not be what you intended.
Mistake 4: Ignoring pull conflicts. Some developers abort conflicts and avoid pulling, letting their branch drift further from the remote, making the eventual resolution worse.
Interview Questions
Q1: What does git pull actually do internally?
Git pull is git fetch followed by git merge. Fetch downloads new commits and updates remote-tracking branches without changing your working directory. Merge then integrates those fetched changes into your current local branch, either via fast-forward or by creating a merge commit.
Q2: What is the difference between git pull and git pull --rebase?
Regular pull creates a merge commit when branches have diverged, preserving the exact branching history. Pull with rebase replays your local commits on top of the fetched remote changes, producing a linear history without merge commits. Rebase is preferred for feature branches.
Q3: How do you handle conflicts during git pull?
Open the conflicted files, resolve the conflict markers (choosing the correct content), stage the resolved files with git add, and complete with git commit (for merge) or git rebase --continue (for rebase). You can abort entirely with git merge --abort or git rebase --abort.
Q4: When should you use git pull --ff-only?
Use it on long-lived shared branches like main where you want to ensure your local copy only fast-forwards. If the pull would require a merge (meaning you have local commits not on the remote), it fails instead of creating an unexpected merge commit. This catches workflow mistakes early.
Q5: Should you always pull before pushing?
Yes, if the remote has changes you do not have. Git enforces this by rejecting pushes that would not fast-forward. However, if you are the only person working on a branch and you know the remote has not changed, a push without pulling first works fine.
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Git Pull - Fetch and Merge Remote Changes.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Git & GitHub topic.
Search Terms
git-github, git & github, git, github, working, with, repositories, pull
Related Git & GitHub Topics