Module 5 Lesson 3: Fetch vs pull

In the last lesson, we learned that git pull is the standard way to download work. But git pull has a "hidden" side effect: it forces a merge immediately.

In this lesson, we learn about git fetch—the safer, more professional sibling of pull—and why you should use it for better control over your repository.

1. What is `git fetch`?

git fetch downloads all the commits, files, and branches from the remote server to your local machine.

However, it does not change any of your own files in your working directory. It essentially says: "Go see what's new on the server, and tell me about it, but don't touch my local code yet."

Why use it?

You want to see what your teammates have done before you merge it.
You want to see if your local history has diverged from the server.
You are on a plane or train and want to download the latest state so you can work offline later.

2. Comparing Fetch and Pull

Think of it this way:

git pull = Download + Merge (Automatic)
git fetch = Download (Manual Choice)

graph TD
    Remote["Remote Server"] -- "git fetch" --> LocalDB["Local Git Database"]
    LocalDB -- "git merge" --> Files["Your Working Files"]
    
    Remote -- "git pull" --> Files
    
    style Remote fill:#f9f
    style Files fill:#dfd

3. The "Remote-Tracking" Branches

When you run git fetch, Git updates special pointers called Remote-Tracking Branches. These look like origin/main or origin/feature-x.

You can actually check out these branches to see the code exactly as it exists on the server:

git checkout origin/main

(Git will warn you that you are in 'detached HEAD' state, which is fine since you are just looking at the code, not editing it).

4. The Professional Workflow

Instead of just running git pull and hoping for the best, most advanced developers follow this pattern:

git fetch origin: Download the latest data.
git log main..origin/main: See exactly what commits are on the server that you don't have yet.
git diff main origin/main: See the exact code changes.
git merge origin/main: Once you are satisfied, manually trigger the merge.

Lesson Exercise

Goal: Inspect before merging.

In your GitHub repo, make another change on the website (e.g., edit the README).
In your local terminal, run git fetch origin.
Notice that your local files have not changed.
Run git log --oneline main..origin/main. Do you see the commit you just made on the website?
Now, run git merge origin/main.
Notice that your local files are now updated.

Observation: You'll realize that fetch gives you a "Preview" mode for your repository. It allows you to plan your merges rather than reacting to them.

Summary

In this lesson, we established:

git fetch downloads remote data without merging.
Remote-tracking branches (origin/main) allow you to see the server's state.
git log branchA..branchB shows the difference in commits.
Fetch is safer and provides more control than a direct pull.

Next Lesson: We’ll dive deeper into how your local branches "follow" their remote cousins in Lesson 4: Tracking remote branches.