Fetch Without Moving Main

All three repositories currently agree. To see what fetch actually does, you will make one later commit in garden, push it to the bare repository, and fetch it into garden-copy. There is only one writer, so no histories diverge.

Advance garden and its origin

Move from garden-copy back to the prepared garden repository, then open a new delivery note in nano:

cd ../garden
nano -w delivery.txt

Type this one line, save with Ctrl-O and Enter, then leave with Ctrl-X:

Seed delivery: Friday

Stage and commit the saved note with commands you already know:

git add delivery.txt
git commit -m "Record the seed delivery"

garden’s local main now has one commit that the other repositories do not yet have. In lesson 3, -u recorded an upstream for this branch. Because that relationship already supplies the remote and branch, plain git push is enough now:

git push

The push moves main in origin.git to the new commit. It also updates garden’s own origin/main record. garden-copy has not exchanged information since the clone, so both of its refs are still at the seeded commit.

Fetch into the clone

git fetch contacts a configured remote, downloads commits and other objects the current repository lacks, and updates the corresponding remote-tracking refs. It does not move your local branch and does not change the checked-out files.

Move back to the clone and fetch from its default remote, origin:

cd ../garden-copy
git fetch

The word “contacts” here does not imply a network. garden-copy reads the sibling ../origin.git repository directly from disk.

Compare local main with origin/main

Read the remote-tracking history first, then the local branch history:

git log origin/main
git log main
git status

origin/main now includes delivery.txt, because fetch updated the clone’s record of the remote branch. Local main still ends at the seeded List the first plants commit. The clone’s working tree also still has only README.md and plants.txt, and it is clean.

That difference is the durable lesson:

garden main ---------> new delivery commit
origin.git main -----> new delivery commit
garden-copy origin/main -> new delivery commit
garden-copy main ----> seeded List the first plants commit

Fetch brought information into the clone without choosing what to do with its local branch. Combining or advancing work after fetch belongs to the next chapter.

That gap between origin/main and main inside the clone is not a fault to be corrected quickly. It is Git holding two facts apart on purpose: what the other repository contained when you last looked, and what you have decided to do about it. Keeping them separate is what lets you look before you leap.

Deciding what to do about it is chapter 8, and it gets harder in the one way this chapter avoided: there, both sides have moved.