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,70 @@
+# Everyday Git
+
+## The commands you'll actually use constantly
+
+Module 2 gave you the model. This module gives you the six commands that make up the vast
+majority of real, everyday Git usage.
+
+## `git init` — start tracking a project
+
+```
+$ git init
+```
+
+Creates a new, empty repository in the current directory (a hidden `.git` folder holds
+everything). You only run this ONCE per project, at the very beginning.
+
+## `git status` — where do things stand right now?
+
+Shows what's staged, what's modified-but-unstaged, and what's untracked — the single most
+useful command for orienting yourself, and one you'll run constantly, almost reflexively,
+before and after almost every other Git command.
+
+## `git add` — stage a change
+
+```
+$ git add file.txt        # stage one specific file
+$ git add .                # stage everything currently changed
+```
+
+## `git commit` — permanently record what's staged
+
+```
+$ git commit -m "Add configuration loader"
+```
+
+A good commit message describes WHAT changed and, ideally, WHY — future-you (or a teammate)
+reading `git log` months later should understand the change without re-reading the entire diff.
+
+## `git log` — see the history
+
+```
+$ git log --oneline
+a1b2c3d Add configuration loader
+9f8e7d6 Initial commit
+```
+
+## `git diff` — see exactly what changed, before you commit it
+
+```
+$ git diff              # unstaged changes vs. the last commit
+$ git diff --staged     # staged changes vs. the last commit
+```
+
+Reading your own diff before committing is one of the highest-value habits in this entire
+course — catching an accidental leftover debug line, or a change you didn't mean to include,
+BEFORE it becomes a permanent part of history.
+
+## Instructor Notes
+
+**Lesson goal:** Convert Module 2's model into the six commands used in nearly every real Git
+session — this is the fluency floor for everything that follows in ROOT 03.
+
+**Approximate timing:** 15 minutes read; 10 minutes live.
+
+**Common misconception to watch for:** treating `git add .` as always safe — it stages
+EVERYTHING changed, including files you might not have intended to include; `git status` before
+`git add .` is the habit that prevents this.
+
+**Demo idea:** run the full init→status→add→commit→log→diff sequence live, narrating `git
+status`'s changing output at each step.
@@ -0,0 +1,56 @@
+# Demonstration: The Full Cycle, End to End
+
+## OBSERVE
+
+```
+$ git init
+$ git status --short
+(nothing — empty repository)
+```
+
+## HYPOTHESIS
+
+Predict what happens to `git status` after creating a new file.
+
+## INSPECT
+
+```
+$ echo "v1" > app.py
+$ git status --short
+?? app.py
+```
+
+## CHANGE
+
+```
+$ git add app.py
+$ git diff --staged
+v1
+$ git commit -m "Add initial app.py"
+```
+
+`git diff --staged` shows exactly what's ABOUT to be committed — a real, final check before it
+becomes permanent.
+
+## VERIFY
+
+```
+$ git log --oneline
+3f9a1c2 Add initial app.py
+$ git status --short
+(clean)
+```
+
+The complete cycle, verified with real evidence at each step — not "I think I committed it,"
+but confirmed via `git log`.
+
+## Instructor Notes
+
+**Demo goal:** Show `git diff --staged` as the final safety check before a commit becomes
+permanent — a habit worth building explicitly, not just mentioning in passing.
+
+**Approximate timing:** 8 minutes live.
+
+**Common mistake to watch for:** skipping `git diff`/`git diff --staged` entirely and committing
+on faith — a good moment to ask "how would you know if you accidentally staged the wrong
+thing?"
@@ -0,0 +1,39 @@
+# Knowledge Check: Everyday Git
+
+---
+
+**1. What's the difference between `git diff` and `git diff --staged`?**
+
+*Answer:* `git diff` shows unstaged changes (working tree vs. last commit); `git diff --staged`
+shows what's currently staged and about to be committed (staging area vs. last commit).
+
+---
+
+**2. Why is `git add .` potentially risky compared to `git add <specific-file>`?**
+
+*Answer:* It stages EVERYTHING currently changed in the directory, which can accidentally
+include files you didn't mean to commit — checking `git status` first (or using targeted `git
+add`) avoids this.
+
+---
+
+**3. What makes a commit message actually useful months later?**
+
+*Answer:* Describing WHAT changed and ideally WHY, clearly enough that someone (including
+future-you) reading `git log` understands the change without re-reading the full diff.
+
+---
+
+**4. You run `git init` in a directory that already has an existing Git repository. What
+happens?**
+
+*Answer:* `git init` only needs to run once per project — running it again in an already-
+initialized repository is harmless (it won't destroy existing history) but is never actually
+necessary.
+
+## Instructor Notes
+
+**Facilitation:** Question 2 is a good moment to establish "check status before staging broadly"
+as a house habit for the rest of the course.
+
+**Approximate timing:** 5 minutes.
@@ -0,0 +1,32 @@
+# Guided Exercise: Plan a Real Commit Before You Make It
+
+This is a paper exercise — commit to a plan before working in the Lab.
+
+## Your task
+
+You've made three unrelated changes to your working tree: fixed a typo in `README.md`, added a
+new function to `utils.py`, and started (but not finished) an unrelated experiment in
+`scratch.py` you're not ready to commit. Write out the exact sequence of commands you'd use to
+end up with exactly ONE clean commit containing the README typo fix, leaving the other two files
+alone.
+
+## A worked shape to check yourself against
+
+```
+git status
+git add README.md
+git diff --staged
+git commit -m "Fix typo in README"
+git status
+```
+
+The key insight: `git add` lets you choose EXACTLY what goes into the next commit, regardless of
+what else is sitting, unstaged, in your working tree — `utils.py` and `scratch.py` remain
+untouched and uncommitted.
+
+## Instructor Notes
+
+**Facilitation:** This exercise directly tests whether Module 2's staging-area model actually
+stuck — if students reach for `git add .`, that's a sign to revisit the model before the Lab.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced.
@@ -0,0 +1,24 @@
+# Reflection: You Have Real, Permanent History Now
+
+## Reflection questions
+
+1. Look at your own `git log` from this module's Lab. Is your commit message something a
+   stranger (or future-you) could understand without more context?
+2. Which of the six commands from this module do you expect to type the most, going forward?
+
+## Real Ops takeaway
+
+**A real, permanent, inspectable history of your work now exists — this is the actual thing
+Module 1 named as missing from copy-a-file-as-backup.** Every commit you make from here on is
+recoverable, comparable, and explainable. Module 4 builds on this by letting multiple lines of
+work (branches) develop independently before combining — impossible without the reliable
+history you just built the habit of creating.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 1 works well as a peer-review pass —
+have students read a neighbor's commit message and guess what it changed, then compare.
+
+**Approximate timing:** 5-8 minutes live discussion; 5 minutes self-paced writing.