With authentication sorted out, the channel is open. Ana has uploaded task-manager to the team server — the exact mechanics of pushing are the subject of the next lesson — and for the first time in the course there are Git objects on a machine other than her own.

Now for the other direction of travel: receiving. And here we run into the most widespread confusion in the whole of Git, the one that causes the most alarm and fills the most forum threads: the difference between git fetch and git pull.

The confusion is understandable, because the names do not help: one word suggests going out to get something, the other suggests dragging it towards you, and in everyday speech they are near enough interchangeable. In Git they are nothing of the sort:

• git fetch downloads objects and updates your remote references. It does not touch a single file in your working tree. It is a completely harmless operation.
• git pull runs a fetch and then immediately integrates what it downloaded into your current branch. It does modify your files and it can produce conflicts.

Understanding that difference changes your whole relationship with remotes: you move from "I run pull and see what happens" to "I look at what is there, I decide, and then I integrate". This lesson takes it apart, and Carla finally clones the project and catches up.

1. The starting point: the project is already on the server
2. git fetch: what it actually does
3. Before and after a fetch
4. FETCH_HEAD: the reference almost nobody knows about
5. Inspecting what arrived before integrating it
6. Integrating by hand: merging origin/main
7. git pull = fetch + integration
8. The modes of git pull
9. Cleaning up stale references: --prune
10. Carla joins and catches up
11. When histories diverge

Where the team stands right now:

Ana has published. Bruno has already updated his clone. Carla has nothing at all.

To reproduce this on your own machine, we build the whole scenario out of what the previous lessons taught:

Four commits on the server and two repositories in sync. That is our starting point.

Bruno sits down to work in the morning. Ana has been adding things since yesterday and has pushed two new commits. Bruno has no idea: he remembers from lesson 04-01 that his origin/main is a photograph dated yesterday and that nobody is going to tell him otherwise.

Let us simulate Ana's work:

And now Bruno:

The line that matters is the last one, and it repays a careful reading:

What has been updated is origin/main, not main. That arrow says so literally: the main branch on the server has been stored in your origin/main reference. It is the refspec from lesson 04-02 in action.

1. It connects to the remote and asks which references it has.
2. It downloads the objects you are missing (commits, trees, blobs) and stores them in .git/objects/.
3. It updates the remote references in .git/refs/remotes/origin/ according to the configured refspec.

1. It does not touch your working tree. Not one file. Not one.
2. It does not move any of your local branches. Your main stays exactly where it was.
3. It cannot produce conflicts. There is nothing to combine: objects are added and pointers move on references that are not yours.

The proof is immediate:

That closing nothing to commit, working tree clean is the point: the fetch has changed nothing on disk. The only thing that is new is that Git now knows two commits are waiting, because it can compare main against origin/main. Exactly where that message comes from and how it is worked out is the subject of lesson 04-06.

Two references, two different commits. This is the normal state of affairs after a fetch, and there is nothing odd about it.

The single most important practical consequence of this lesson: git fetch is absolutely safe. It cannot break anything, it cannot lose work, it cannot produce a conflict and it cannot leave you halfway through anything. Run it whenever you like, even with uncommitted changes in your working tree. The only consequence is that you will be better informed.

And one that downloads nothing at all and is extremely handy for diagnosis:

It asks the server which references it has and which commits they point at, without downloading a single object. It is the cheapest way to check whether there is anything new or whether the remote is answering at all.

Seen on the graph, which is where it makes the most sense:

Notice the two details that sum up the whole lesson:

1. Two new commits have appeared (9e2f4a7 and b4d7e93) in Bruno's object database. They are there, complete, and readable offline.
2. main has not moved. It is still on c2a8f1e, exactly where it was. Only origin/main has advanced.

And because the objects are already on his disk, Bruno can examine them with everything he learned in module 2, with no network and without having integrated anything:

This is one of the great advantages of the distributed model: downloading and deciding are two separate acts. You can pull down the whole team's work on the train, on a patchy connection, and study it at your leisure afterwards.

Every git fetch writes a file at the root of .git/:

FETCH_HEAD records what came down in the last download operation. It has three columns:

That not-for-merge is the key: it marks the branches that came across because of the refspec but that are not the one you would integrate. Only the tracking branch of your current branch is left unmarked.

You can use it like any other reference:

First: it is the internal mechanism of git pull. When you run git pull, Git performs a fetch and then a git merge FETCH_HEAD. Knowing that strips the command of all its mystery: there is no magic, just two steps chained together.

Second: it lets you fetch from a URL without registering any remote. This comes up more often than you would think — for instance, when reviewing work from someone outside the team:

It is ephemeral: every fetch overwrites FETCH_HEAD. If you are going to need that commit later on, create a branch or a named reference; otherwise garbage collection will eventually carry it off.

Here is the professional habit that separates the people who understand Git from the people who suffer it: between the fetch and the integration there is a gap, and that gap is for looking.

Bruno already has Ana's commits on his disk. Before mixing them into his own work, he studies them.

Recall the semantics of the a..b range from module 2: "commits reachable from b but not from a". In other words: what the server has and I do not.

Empty: Bruno has committed nothing since his last synchronisation. If there were commits here and in the previous range, the histories would have diverged; that case is section 11.

A quick look at the surface of the change. And if you want the detail:

The unified diff of lesson 02-05, with nothing different about it: origin/main is a reference like any other.

The --all option includes every reference, remote ones included. It is the view to keep at hand the moment you start working with a remote.

This is the recommended flow: fetch → look → decide → integrate. It costs twenty seconds and saves you the bewilderment of a pull that has suddenly modified fifteen files you were not expecting.

Bruno has seen what is there and he is happy with it. Now he integrates:

And this is exactly the git merge of module 3. Nothing new. Since Bruno had no commits of his own, main was simply behind without having diverged, and Git applied a fast-forward: moving the pointer forward. The same case we studied with local branches.

Now all three references agree: main, origin/main and the branch on the server.

This is the point at which it is worth pausing for a moment, because it delivers on the promise made at the end of module 3:

Integrating someone else's work is exactly the same git merge you have used with your own branches. Fast-forward if you have not diverged, three-way merge if you have, with the possibility of conflicts you already know how to resolve. Remotes change none of that: all they change is where the commits come from.

And with that, git pull stops being mysterious:

git pull is a shortcut for git fetch followed by an integration of the tracking branch into your current branch.

It really is that literal. These two blocks do the same thing:

The two halves have opposite natures, which is why it pays to see them apart:

Use git fetch when:

• You want to know what is new without committing to anything.
• You have uncommitted changes and you want nothing to move.
• You are in the middle of something delicate.
• You want to review someone else's work before mixing it in.
• You are about to lose your connection and want everything downloaded.

Use git pull when:

• You are starting the day and simply want to catch up.
• You are sure you have not diverged.
• You are working on a branch nobody else touches.

An honest recommendation: if you are starting out, get into the habit of git fetch + look + integrate. It is one extra step and fifteen seconds, but it gives you the right mental model and avoids 90% of the frights. Once you understand perfectly well what is going to happen, git pull is a legitimate shortcut.

The fetch half of pull is always the same. What varies is how it integrates, and there are three possible behaviours. This is why, back in lesson 01-06, we configured:

It integrates only if the result can be reached with a fast-forward — that is, if your branch has no commits of its own. If you have diverged, it stops without doing anything:

This is not an error: it is the configuration working. Git is telling you "there is a decision to be made here and I am not going to make it for you". It is exactly what we wanted when we set pull.ff only in the initial configuration: never create merge commits by surprise.

It is the most conservative mode and the best one while you are learning.

It integrates with git merge. If it can fast-forward, it does; if you have diverged, it creates a merge commit with two parents.

This was Git's historical default behaviour, and it is the reason so many repositories are littered with commits entitled Merge branch 'main' of https://…. Every one of them is somebody who ran git pull while diverged, without realising they were creating a commit.

That noise in the history is, precisely, one of the problems module 5 will tackle.

Instead of merging, it reapplies your local commits on top of what it fetched from the server, producing a linear history with no merge commits.

It is a powerful and very widely used technique, but it rewrites your local commits — it changes their hashes — and it comes with important rules about when you may and may not use it. It deserves a lesson of its own, and it has one: lesson 05-01: Rebase. Until then, just remember that the option exists and what it does in one sentence.

And the corresponding configuration, which you already know from lesson 01-06:

You can also fine-tune it per branch:

If you have uncommitted modifications and the integration needs to touch those same files, Git refuses:

And rightly so: it is protecting work that exists only on your disk. The options are to commit, or to stash the changes temporarily with git stash (the subject of lesson 05-04).

Note that a git fetch in that same situation would have worked perfectly well, because it does not touch the working tree. One more reason to prefer it.

Over time a small but irritating problem appears. The team integrates the feature/task-counter branch and deletes it from the server. But in Bruno's repository, the reference origin/feature/task-counter stays there for ever.

Why? Because the default refspec only says what to fetch, not what to delete. A normal fetch never removes remote references.

Two ghost references. And git remote show origin gives them away:

That stale is exactly what we saw in lesson 04-02: "you have this reference, but it is no longer on the server."

And to see what would be deleted without deleting anything:

Since this has to be done all the time and has no downside whatsoever, the sensible thing is to configure it once and for all:

From now on, every fetch and pull of yours clears out the dead references. It is one of the settings a team repository with a high branch turnover appreciates most.

And if you also want to clear out tags deleted on the server:

This last one needs more care, because tags tend to be permanent and deleting one locally may not be what you want. Tags are the subject of lesson 05-05.

Very important: prune deletes remote references, never local branches or commits. If you have a local branch feature/task-counter, it is still there untouched after the prune. All that disappears is the note saying "the server had this branch".

The moment we announced at the close of module 3 has arrived.

Carla, on her Windows 11 machine, with Git installed (lesson 01-02), configured (lesson 01-06) and her SSH key generated, loaded and uploaded (lesson 04-03), opens Git Bash and types the command Bruno ran in lesson 02-02:

But this is not the same clone Bruno made. His was a newborn repository with two commits. This one has months of work inside it:

There is the entire story of module 3, with its three-way merges, its squash and its resolved conflict, downloaded in full onto Carla's laptop. She can consult any commit from any point in time with no connection at all because — as she knows from lesson 04-01 — her repository is complete and independent.

And everything lesson 02-02 said about what a clone leaves configured:

Notice a detail that confuses a lot of people when they join a project: Carla has only one local branch (main), even though the server has several. The others exist in her repository as remote references, not as branches of her own. To work on one:

Git saw that the local branch did not exist but origin/docs/update-notes did, worked out what she meant, and created the local branch with its tracking configured. That behaviour is called DWIM and it is one of the topics of lesson 04-06.

Carla is up and running. Her daily routine will look like this, and it is the routine of anyone working with a shared repository:

Three commands in the morning. That is the whole ritual.

One case is still missing, and it needs naming even though we will not develop it here.

Suppose Carla has committed two commits on main while Ana was pushing another three. The two histories have now diverged: each has commits the other does not. It is the scenario we studied in lesson 03-01 with local branches, except that now one of the two "branches" lives on another machine.

With pull.ff only configured:

Once again: this is not a failure, it is the protection working. Git refuses to choose between merging and rewriting on your behalf, and it is right to: those decisions have different consequences for the team's history.

There are several ways out — merge explicitly, reapply your commits with rebase, or rethink the work — and each has its own implications and contraindications. All of that, with the criteria for choosing and the full procedures, is the subject of lesson 09-03: Resolving Divergence with the Remote.

Here it is enough that you recognise the message, that you understand why it appears (both sides have moved on separately from a common ancestor) and that you are clear that nothing has broken and nothing has been lost: there is simply a decision outstanding.

The same thing will happen in the opposite direction, when you try to push and the server rejects it. It is exactly the same situation seen from the other side, and we will meet it in the next lesson.

Mistake 1: believing git fetch did nothing because "the files look the same". It did precisely what it should: download objects and update origin/main. Check with git log --oneline main..origin/main and you will see everything it brought.

Mistake 2: running git pull blind and being surprised by the result. If you have diverged and your pull is in merge mode, you have just created a merge commit you may not have wanted. fetch + look + integrate costs fifteen seconds and removes the surprises.

Mistake 3: reading fatal: Not possible to fast-forward as a serious error. It is pull.ff only doing its job: there is divergence and Git will not decide for you. See 09-03.

Mistake 4: never using --prune. After a year you have forty origin/… references for branches deleted months ago, autocompletion is useless and git branch -r is unreadable. Set fetch.prune true and forget about it.

Mistake 5: thinking origin/main updates itself. It is a file on your disk. It changes only with fetch, pull, clone or a successful push. If a colleague tells you "it is already up there" and you cannot see it, your first command is git fetch.

Mistake 6: running pull with uncommitted changes and getting stuck on the error. The message is clear: commit or stash. And remember that a fetch in that same situation would have worked without trouble.

Mistake 7: confusing git remote prune with git prune. They are different commands: the first clears stale remote references; the second is a maintenance operation on the object database that removes unreachable objects. Do not mix them up.

Tip 1: make git fetch --prune the first command of your day. It is free, it is safe and it tells you where you stand. Then you decide what to do.

Tip 2: keep an alias for viewing the graph with the remote references.

With git gr you see at a glance where you are, where the server is and which branches sit in between. Aliases are covered in depth in lesson 06-04.

Tip 3: use git ls-remote to check the server without downloading anything. It is instantaneous and perfect for answering "is it up there yet?" or "is this remote responding?".

Tip 4: if you are about to travel or lose your connection, run git fetch --all --tags first. You take the whole team's work with you on disk and can review it, compare branches and read the history with no network.

Tip 5: git fetch is safe. Run it without fear. There is no situation in which a fetch spoils anything. Internalising that is what lets you work with remotes calmly.

Set up a bare server and two clones standing in for Ana and Carla. Then:

1. Ana commits and pushes two commits.
2. Carla, before doing anything, notes the hash of her main and of her origin/main, and keeps a copy of the contents of a file.
3. Carla runs git fetch.
4. Demonstrate with commands that: (a) origin/main has changed, (b) main has not, (c) the file on disk is identical and (d) the new commits are already in her object database.
5. Now integrate and check what kind of integration Git performed, and why.

Starting from the previous exercise, and without integrating, answer each question with a single command:

1. How many commits am I missing?
2. Who wrote them and when?
3. Which files do they modify, and by how many lines each?
4. What exactly changes in app.js?
5. Do I have any commit the server does not have?
6. What does the graph look like with every reference?

1. Create three branches on the server in addition to main.
2. Clone and check that all three appear as remote references.
3. Delete two of them on the server.
4. Run a normal git fetch and check that the ghost references are still there.
5. Explain why the fetch did not remove them.
6. Clean them up both possible ways and configure Git so it does not happen again.

Solution 1:

Exactly the same hash as before the fetch.

Same checksum, and git status --short with not a single line: the working tree is untouched.

This is the key demonstration: Carla can examine the full contents of commits she has not integrated, with no connection, because the objects are in her .git/objects/. What has not changed is her branch or her files.

Fast-forward, and the reason is in the graph: Carla had committed nothing, so her main was a direct ancestor of origin/main. There was no divergence and no merge commit was needed: moving the pointer was enough. You can check it formally:

Solution 2:

Going back to the state just after the fetch and before the merge:

The -- separates references from paths, so that Git need not wonder whether app.js is a file or a branch.

Nothing. I have not diverged, so the integration will be clean. The compact version of the same question:

Zero commits exclusively mine, two of theirs. (This syntax is explained in depth in lesson 04-06.)

A single straight line with main behind: the visual image of "I can fast-forward".

Solution 3:

The two ghosts are still there. And git remote show confirms it:

5. Why the fetch did not remove them: because the default refspec, +refs/heads/*:refs/remotes/origin/*, only describes what to fetch. It is a copying instruction, not a synchronisation one: it says "whatever branches exist over there, store them here", and it says nothing about what to do with the ones that no longer exist. Deleting references is extra behaviour you have to ask for explicitly, and Git is conservative by default: it does not remove things unless you tell it to.

From now on, every fetch and pull cleans up by itself. And one final reassuring check:

prune deletes remote references, nothing more.

This lesson has undone the most widespread confusion in Git. The essentials:

• git fetch downloads objects and updates your remote references. It does not touch the working tree, it does not move your branches and it cannot produce conflicts. It is a completely safe operation you can run at any time, even with uncommitted changes.
• git pull is git fetch + an integration into your current branch. The first half is harmless; the second modifies your files and can produce conflicts. Seeing them separately is what takes the mystery out of the command.
• The output c2a8f1e..b4d7e93 main -> origin/main means: the server's main branch has been stored in your local origin/main reference. Your main has not moved.
• FETCH_HEAD records what came down in the last fetch, with the not-for-merge mark on the branches that are not candidates for integration. It is the internal mechanism of pull and it lets you fetch from a URL without registering a remote.
• Between the fetch and the integration there is a gap, and it is for looking: git log main..origin/main, git diff --stat main origin/main, git log --oneline --graph --all. Twenty seconds that remove the surprises.
• Integrating remote work is the same git merge of module 3: fast-forward if you have not diverged, three-way merge if you have. All remotes change is where the commits come from.
• The modes of pull: --ff-only (ours, thanks to pull.ff only) stops at divergence instead of deciding for you; --no-rebase merges and creates merge commits; --rebase reapplies your commits and is studied in lesson 05-01.
• git fetch --prune and git remote prune remove the references of branches already deleted on the server, which a normal fetch never clears. Set fetch.prune true and forget about it. It deletes only remote references: never local branches or commits.
• Carla is in: she has cloned a repository with the full history, she has origin configured, one local branch and remote references for the rest.
• If the histories diverge, pull --ff-only stops. That is not a failure: it is a pending decision. The full treatment is in lesson 09-03.

You now know how to receive. The other half is missing, and it is the one with consequences for the whole team: sending.

In lesson 04-05: Pushing Changes we will see what git push actually sends (objects and the update of a reference), what that -u in every tutorial does, how a push refspec is written and why it connects directly with what we studied in 04-02. And above all: why a push can be rejected, what non-fast-forward means exactly, and why --force-with-lease is almost always the right answer when --force can destroy a colleague's work without a trace.