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,54 @@
+# Engineering Git Workflow
+
+## Small commits, meaningful messages
+
+A commit containing "fixed stuff" and 40 unrelated file changes is nearly useless to anyone
+reading history later — including future-you. A commit that does ONE logical thing, with a
+message describing what and why, is what actually makes `git log` a useful tool rather than
+noise. This isn't pedantry — it's what makes rollback (below) and code review actually
+practical.
+
+## `main` as a protected source of truth
+
+Real engineering teams treat their main branch as the one everyone trusts to be in a working
+state at all times — direct, unreviewed pushes to `main` are typically restricted specifically
+BECAUSE it's the shared source of truth every deployment and every other branch is built from.
+Feature branches (Module 4) exist precisely so risky, in-progress work never threatens that
+trust.
+
+## Review: another set of eyes before history is permanent
+
+Before a change reaches `main`, most real teams have someone else look at it first (a "pull
+request" or "merge request," depending on the platform). This isn't about distrust — it's a
+second perspective catching mistakes, and a natural point to discuss WHY a change is being made,
+not just what it does.
+
+## History and rollback as safety nets
+
+Because every commit is permanent and inspectable, a bad change can be identified precisely (via
+`git log`) and reverted deliberately — confident recovery, not panic, when something goes wrong.
+This is Module 1's original promise, now fully realized: reproducibility and rollback aren't
+theoretical, they're what your daily small-commit discipline actually buys you.
+
+## Why this matters to DevOps, GitOps, and Infrastructure as Code
+
+Everything in this lesson — small deliberate changes, a trusted source of truth, review before
+merge, reliable history — is EXACTLY what CI/CD pipelines automate, what GitOps treats a Git
+repository as authoritative for, and what Infrastructure as Code relies on to safely manage real
+infrastructure through the same discipline you just practiced on plain text files. ROOT 11
+builds directly on this course's habits, not a new set of ideas.
+
+## Instructor Notes
+
+**Lesson goal:** Close ROOT 03 by explicitly naming the professional discipline (not just Git
+commands) this course was building, and its direct connection to DevOps/GitOps/IaC.
+
+**Approximate timing:** 15 minutes read; 10 minutes live.
+
+**Common misconception to watch for:** treating "review" and "protecting main" as bureaucratic
+overhead rather than genuine risk management — connect it back to the real cost of a bad change
+reaching a shared source of truth unreviewed.
+
+**Discussion question:** "Why might a team enforce small commits and review even when working
+alone on a personal project?" (Good answers: future-you benefits from the same clarity; building
+the habit now pays off the moment you DO work with others.)
@@ -0,0 +1,47 @@
+# Demonstration: The Same Change, Told Two Ways
+
+## OBSERVE
+
+```
+$ git log --oneline
+a1b2c3d fixed stuff
+```
+
+One commit, an unhelpful message, and (imagine) 15 unrelated files changed together: a bug fix,
+a typo correction, and an unrelated half-finished experiment.
+
+## HYPOTHESIS
+
+Predict: six months from now, could you (or a teammate) confidently `git revert` just the bug
+fix from this commit, leaving the other 14 files untouched?
+
+## INSPECT
+
+No — reverting this ONE commit reverts everything in it together, including the unrelated
+typo fix and experiment, whether you want that or not.
+
+## CHANGE
+
+The same work, done as three separate, well-described commits instead:
+
+```
+$ git log --oneline
+3f9a1c2 Fix null-pointer crash in payment retry logic
+9d8e7f6 Fix typo in onboarding email template
+1a2b3c4 WIP: experiment with new caching strategy (not ready)
+```
+
+## VERIFY
+
+Now `git revert 3f9a1c2` cleanly undoes JUST the payment bug fix, with zero effect on the other
+two — because each commit is one logical, independently-reversible unit of work.
+
+## Instructor Notes
+
+**Demo goal:** Make the practical cost of "fixed stuff" commits concrete — not a style
+preference, a genuine loss of capability (precise revert, clear history, easier review).
+
+**Approximate timing:** 8 minutes live.
+
+**Common mistake to watch for:** treating this as a purely aesthetic preference rather than a
+practical one — reinforce the concrete "can you revert just the bug fix" test.
@@ -0,0 +1,32 @@
+# Knowledge Check: Engineering Git Workflow
+
+---
+
+**1. Why does bundling unrelated changes into one commit cost you something real, not just
+style points?**
+
+*Answer:* It makes precise operations like `git revert` impossible to apply to just ONE logical
+change — reverting the commit reverts everything in it together, whether you want that or not.
+
+---
+
+**2. Why do teams typically restrict direct, unreviewed pushes to `main`?**
+
+*Answer:* `main` is the shared source of truth everything else (deployments, other branches) is
+built from — protecting it reduces the chance an unreviewed mistake reaches something everyone
+else depends on being trustworthy.
+
+---
+
+**3. Name one concrete way this course's Git discipline connects to GitOps or CI/CD.**
+
+*Answer:* Any reasonable answer connecting small deliberate changes / a trusted source of truth
+/ review-before-merge / reliable history to how CI/CD pipelines trigger on pushes or how GitOps
+treats a Git repository as the authoritative record of desired infrastructure state.
+
+## Instructor Notes
+
+**Facilitation:** Question 3 is open-ended by design — the goal is students making the
+connection in their own words, not reciting a fixed answer.
+
+**Approximate timing:** 5 minutes.
@@ -0,0 +1,30 @@
+# Reflection: You've Practiced Real Engineering Discipline, Not Just Syntax
+
+## Reflection questions
+
+1. Look back across all six modules of ROOT 03. Which single habit (small commits, checking
+   `git status` before staging, fetch-before-pull, resolving conflicts deliberately) do you
+   think will matter most in real work?
+2. This course started with "copying files as backup isn't version control." Can you now
+   explain, in one sentence, what Git actually gives you that copying never could?
+
+## Real Ops takeaway
+
+**Version control discipline is not a Git-specific skill — it's an engineering discipline that
+happens to be exercised through Git.** Small deliberate changes, a trusted shared source of
+truth, review before permanent history, and confident rollback are the same principles behind
+CI/CD, GitOps, and Infrastructure as Code, all covered later in ROOT 11. You are not starting
+that content from zero — you already practiced its foundation here.
+
+This module — and ROOT 03 — is complete. Continue to ROOT 04: Containers & Docker.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 2 is a good closing check — a clear,
+confident answer here is real evidence the course's central premise landed.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.
+
+**Milestone note:** this is the last module of ROOT 03 — consider a brief recap connecting all
+six modules (why version control → the three-area model → everyday commands → branching/
+conflicts → remotes → professional workflow) before moving to ROOT 04.