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
parent e007bcf000
commit e68b6f445a
33 changed files with 1393 additions and 0 deletions
@@ -0,0 +1,40 @@
+# Why Version Control Exists
+
+## The problem: `final.txt`, `final_v2.txt`, `final_v2_ACTUALLY_FINAL.txt`
+
+Before version control, "keeping history" usually meant copying a file with a new name every
+time something changed. This fails fast: you lose track of WHAT changed between versions, WHO
+changed it, and WHY — and it gets completely unworkable the moment more than one person touches
+the same project.
+
+## What version control actually gives you
+
+- **History** — every change, in order, permanently. You can see exactly what a file looked
+  like at any point in the past.
+- **Reproducibility** — you can recreate the EXACT state of an entire project at any past
+  moment, not just one file.
+- **Collaboration** — multiple people can work on the same project without emailing files back
+  and forth or overwriting each other's work.
+- **A source of truth** — one authoritative history everyone agrees is correct, instead of
+  "whoever has the newest-looking filename."
+- **Rollback** — if a change turns out to be wrong, you can return to a known-good prior state
+  with confidence, not by hoping you kept a backup copy somewhere.
+
+## Why copying files isn't version control
+
+Copying `app.py` to `app_backup.py` before making a risky change LOOKS like version control, but
+it has none of version control's real properties: no record of WHY the change was made, no way
+to see incremental history, no way to combine two people's simultaneous edits, and no
+scalability past a handful of files. Git (and version control generally) tracks CHANGES over
+time as a structured history, not disconnected snapshots you have to manually manage.
+
+## Instructor Notes
+
+**Lesson goal:** Motivate Git before teaching a single command — students should feel the real
+problem (the `final_v2_ACTUALLY_FINAL.txt` pattern) before the solution makes sense.
+
+**Approximate timing:** 10 minutes read; 8 minutes live.
+
+**Discussion question:** "Has anyone ever lost work, or overwritten someone else's work, because
+of exactly this kind of file-copying problem?" (Real personal stories land this lesson far
+better than abstract description.)
@@ -0,0 +1,31 @@
+# Knowledge Check: Why Version Control Exists
+
+---
+
+**1. Name three real properties version control gives you that copying files as backups
+doesn't.**
+
+*Answer:* Any three of: structured history of every change, reproducibility of exact past
+states, real collaboration between multiple people, a single agreed-upon source of truth,
+confident rollback to a known-good state.
+
+---
+
+**2. Why does `final_v2_ACTUALLY_FINAL.txt` fail as a version-control strategy?**
+
+*Answer:* It has no record of what changed or why between versions, doesn't scale past a
+handful of files, and provides no way to merge two people's simultaneous changes.
+
+---
+
+**3. What does "source of truth" mean in the context of version control?**
+
+*Answer:* One authoritative, agreed-upon history of a project that everyone treats as
+correct — as opposed to ambiguity over which copy or filename is the "real" current version.
+
+## Instructor Notes
+
+**Facilitation:** Keep this brief — it's checking motivation/vocabulary before the hands-on
+modules begin, not testing depth yet.
+
+**Approximate timing:** 4 minutes.
@@ -0,0 +1,25 @@
+# Reflection: Naming the Problem You're About to Solve
+
+## Reflection questions
+
+1. Have you personally ever lost work, or been confused about which file version was current,
+   in a way version control would have prevented?
+2. What do you expect to feel DIFFERENT about how you work once you have real history and
+   rollback available?
+
+## Real Ops takeaway
+
+**Every engineering practice this program builds toward — code review, CI/CD, GitOps,
+infrastructure as code — assumes version control as its foundation.** You cannot meaningfully
+automate deployment, review changes before they ship, or declare infrastructure as code without
+first having a reliable, structured history of what changed and when. This module named the
+problem; the rest of ROOT 03 gives you the tool.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 1 tends to produce genuine, motivating
+stories — let students share before moving to Module 2's mental model.
+
+**Approximate timing:** 5 minutes live discussion; 3 minutes self-paced writing.