Files

T

ced4568andClaude Sonnet 5 e68b6f445a feat(root03): author Git & Collaborative Development

Adds all 6 ROOT 03 modules (why version control exists, the Git mental model, everyday Git,
branching & merging, remote repositories, engineering Git workflow) — 31 activities. Uses only
real LOCAL Git repositories throughout — no Gitea account, no network access, and no
RootNode-canonical-repo credential is ever needed or exposed in a student Lab
(docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md §4). Modules 1, 2, and 6 are conceptual bookends with no
lab, matching the flexible readiness standard already used in ROOT 01/02.

Adds 3 new hands-on Git scenarios plus 2 MCQs: git-everyday-basics (init/add/commit, validated
by inspecting real `git log`/`git show` state, not just command output strings — Step 6's
explicit requirement), git-branching-and-merge (a REAL merge conflict caused on purpose by two
branches editing the same line, resolved by the student, validated by confirming the conflict
markers are gone and a real two-parent merge commit exists), and git-remote-clone-push (a real
local bare repository standing in for a remote — clone/commit/push validated by inspecting the
REMOTE side directly, not just the student's own clone). All tested end-to-end via the real
scenario-validation API, including negative tests.

Wires rootnode-git-fundamentals-assessment (2 required + 3 random-draw scenarios) using the
existing Phase 3B assessment engine.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

2026-08-26 17:08:00 -05:00

2.9 KiB

Raw Blame History

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.)

2.9 KiB Raw Blame History