# Remote Repositories

## What a remote actually is

Every repository you've worked with so far has been entirely LOCAL — on this one machine. A
**remote** is a reference to another copy of the same repository, typically hosted somewhere
else (a server, or in this Lab, a second local repository playing that role). Remotes are what
make real collaboration possible: multiple people, multiple machines, all synchronizing through
one shared history.

## `origin`: a name, not a special concept

By convention, the remote you cloned FROM is named `origin` — but this is just a label Git
assigns automatically, not a technical requirement. You could name a remote anything; `origin`
is simply the default everyone recognizes.

## The four remote operations

- **`git clone <url>`** — copy an ENTIRE remote repository (full history included) to a new
  local directory, automatically configuring it as `origin`.
- **`git fetch`** — download the remote's latest commits WITHOUT changing your own working
  files or branches — a safe way to see what's new before deciding what to do about it.
- **`git pull`** — fetch AND immediately merge the remote's changes into your current branch —
  effectively `fetch` + `merge` in one step (which is exactly why a `pull` can produce a merge
  conflict, the same as Module 4's local merges).
- **`git push`** — upload your local commits to the remote, making them visible to everyone else
  using that remote.

## Upstream: your branch's remote counterpart

A local branch can be configured to TRACK a specific remote branch (its "upstream") — once set,
plain `git pull`/`git push` (no extra arguments) know exactly which remote branch to sync
against, rather than requiring you to specify it every time.

## RootNode uses Gitea (this course does not)

RootNode's own engineering team uses Gitea (a self-hosted Git service) for its real work — the
CONCEPTS in this lesson (origin, clone, fetch, pull, push) are identical regardless of which
service hosts a remote (Gitea, GitHub, GitLab, or a private server). This course teaches those
concepts using a disposable LOCAL repository standing in for a remote — no account, no network
access, and no RootNode credentials are ever needed or exposed in this Lab.

## Instructor Notes

**Lesson goal:** Teach remotes as a genuine, transferable concept — students should be able to
work with ANY real Git hosting service afterward, not just this Lab's local simulation.

**Approximate timing:** 15 minutes read; 10 minutes live.

**Common misconception to watch for:** treating `git pull` as a "safe, no-side-effects" command
— it's a merge, and merges can conflict, exactly like Module 4 taught.

**Discussion question:** "Why might a team prefer `git fetch` followed by manually reviewing
changes, over always running `git pull` directly?" (Answer: fetch lets you see what changed
before it touches your own working files/branch — useful caution before merging in unfamiliar
changes.)