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]>
3.1 KiB
Git Mental Model
Three places your files can be
Git tracks your project through three distinct areas, and understanding this model is what makes every Git command make sense — memorizing commands without it just produces confusion the first time something doesn't behave as expected.
Working Tree → Staging Area → Repository (commit history)
(your actual (what you've (permanent,
files, as you marked ready recorded
edit them) to commit) snapshots)
- Working tree — the actual files on disk, exactly as you're editing them right now.
- Staging area (also called "the index") — a holding area for changes you've deliberately marked as ready to be committed. This is Git's most distinctive design choice: you don't commit "everything that changed," you commit "exactly what you staged."
- Repository — the permanent, recorded history of every commit ever made — this is what
git logshows you.
Why git add exists at all
A change starts in your working tree. git add <file> moves it (conceptually — the mechanics
are more subtle, but this framing is enough for now) into the staging area. git commit takes
EVERYTHING currently staged and permanently records it as a new snapshot in the repository's
history. This two-step process (stage, then commit) exists so you can build up a commit
DELIBERATELY — staging exactly the related changes that belong together, even if your working
tree currently has other, unrelated changes you're not ready to commit yet.
Core vocabulary
- Commit — one permanently recorded snapshot, with a message describing what changed and why, and a unique identifier (a hash).
- Branch — a movable pointer to a specific commit, letting you develop something (a "feature branch") without affecting the main line of history until you're ready to combine it back in (Module 4).
- HEAD — Git's pointer to "which commit you're currently looking at" — almost always the tip of whichever branch you have checked out.
- Remote — a reference to another copy of the same repository, usually hosted somewhere else (Module 5).
Instructor Notes
Lesson goal: Establish the three-area model BEFORE any commands — same "model before syntax" pedagogy as ROOT 01's process model and ROOT 05's Kubernetes mental model. Every subsequent Git command should be explainable in terms of moving something between these three areas.
Approximate timing: 15 minutes read; 10 minutes live, ideally with a literal diagram drawn live (whiteboard or shared screen) showing files moving between the three areas.
Common misconception to watch for: assuming git commit commits every changed file
automatically — this is the single most common Git surprise for beginners, and it's exactly
what Module 3's Lab will make concrete.
Discussion question: "Why would you ever WANT to stage only some of your changes, not all of them?" (Answer: to build one commit about ONE logical change, even if your working tree currently has several unrelated edits in progress.)