<aside> 🔀
Module 8 — Remotes (git clone, fetch, pull, push). Everything so far happened on one machine — which, per Module 1, was the point of a distributed VCS. Now we connect copies. The four network commands (clone, fetch, pull, push) move snapshots between repositories, and one idea — the remote-tracking branch — makes their behavior predictable. You will build a real "server" on your own disk, so every exercise works offline.
🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start. You need Module 6 (merging — pulls can merge) and Module 7 (the shared-history rules). Exercises continue the kitchen repository from Module 7's end state. No internet or account is needed — the "remote" lives on your disk, which is a fully legitimate Git remote.
</aside>
<aside> 🖼️
This page contains Mermaid diagram blocks. Notion shows them as code by default — click the block and switch it to Preview to see the diagram. You only need to do this once per block.
</aside>
<aside> 📖
Official docs: Git Book §2.5 — Working with Remotes · git-init manual
</aside>
A remote is nothing more than a nickname for another copy of the repository — a name bound to an address (URL or filesystem path), stored in .git/config. There is no special "server software" in Git itself: the thing GitHub hosts, and the thing you are about to create in a directory, is a bare repository — a repository with no working tree: just the contents of .git, standing alone. Why bare? Because nobody edits files on the meeting-point copy; it only receives and serves snapshots — and pushing into a repository where someone has files checked out would yank the working tree out from under them, so Git refuses that by default. Convention names bare repo directories with a .git suffix: project.git.
🧪 Exercise 8.1 — build the "server" on your own disk
cd ~/git-course
git init --bare bakery.git
ls bakery.git
<aside> 📮
Real-world analogy — the PO box
A remote is a PO box: a named address (origin = "the box on Main Street") where copies of your work are dropped off and picked up. The box itself is bare — nobody lives there, no desk, no editing; it exists purely for exchange. Renting a second box under another name (backup, upstream) is routine, and each correspondent keeps their own private note of what was in the box last time they checked.
Where the analogy stops working. A PO box holds whatever was last deposited; old contents leave when picked up. A bare repository is an accumulating database: every snapshot ever pushed stays (immutable objects, Module 3), and a pickup (fetch) copies rather than removes. And unlike mail, exchanges are verified end-to-end — content-addressing means what you fetch provably is what was pushed, hash for hash.
</aside>
<aside> 📖
Official docs: git-remote manual · git-push manual
</aside>
Your kitchen was born locally, so it knows no remotes. Two steps connect it. git remote add origin <address> records the nickname — origin is pure convention (the name clone sets automatically, Part B), used here for consistency. Then the first git push -u origin main does two jobs: uploads main's missing snapshots to the remote and creates its main branch there; and -u (--set-upstream) records that your local main "tracks" origin/main — so future git push/git pull with no arguments know their counterpart, and git status can say "ahead/behind".
🧪 Exercise 8.2 — connect the kitchen and publish main
cd ~/git-course/kitchen
git remote add origin ~/git-course/bakery.git
git remote -v
git push -u origin main
git branch -vv | head -1 # -vv adds each branch's upstream in [brackets]