ced4568andClaude Sonnet 5
e68b6f445a
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]>
1.2 KiB
Guided Exercise: Fetch First, Decide Second
This is a paper exercise — commit to a plan before working in the Lab.
Your task
You're about to sync with a shared remote that a teammate has been actively pushing to all day.
You're not sure what they changed. Write out the SAFER sequence of commands (as opposed to
running git pull immediately), and explain what each step lets you verify before your own
working files are touched.
A worked shape to check yourself against
git fetch origin
git log HEAD..origin/main --oneline
git fetch downloads the new commits without touching your branch. The log command then
shows you exactly what commits exist on the remote that you don't have locally yet — letting you
review WHAT changed before deciding to merge it in with a subsequent git merge origin/main (or
git pull, now that you already know roughly what to expect).
Instructor Notes
Facilitation: This exercise directly builds the "fetch first, review, then merge" habit
real teams use on shared branches — worth connecting explicitly to why blind git pull on a
busy shared branch is a common source of surprise conflicts.
Approximate timing: 8-10 minutes live discussion; 5 minutes self-paced.