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]>
2.1 KiB
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.)