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]>
23 lines
1.4 KiB
JSON
23 lines
1.4 KiB
JSON
{
|
|
"id": "git-staging-area-mcq",
|
|
"title": "A Changed File That Won't Commit",
|
|
"category": "Git",
|
|
"isolation_type": "shared_namespace",
|
|
"difficulty": "Easy",
|
|
"type": "mcq",
|
|
"weight": 3,
|
|
"description": "## A Changed File That Won't Commit\n\nYou edit `config.py`, then run `git commit -m \"update config\"`. The commit succeeds, but when you check `git show`, your changes to `config.py` aren't in it. What Git state should you inspect first?",
|
|
"options": [
|
|
{ "id": "a", "text": "Whether config.py is even tracked by Git at all" },
|
|
{ "id": "b", "text": "The staging area — run `git status` to check whether your changes were actually staged with `git add` before you committed" },
|
|
{ "id": "c", "text": "Whether your internet connection is working" },
|
|
{ "id": "d", "text": "The remote repository's branch protection settings" }
|
|
],
|
|
"correct_option": "b",
|
|
"explanation": "`git commit` only records what's currently in the STAGING AREA, not every change in your working tree. A modified-but-unstaged file is invisible to the next commit — `git status` shows exactly this distinction (\"Changes not staged for commit\" vs. \"Changes to be committed\"), which is why checking the staging area is the right first step, not assuming the file isn't tracked or a network issue (Git is entirely local for this operation).",
|
|
"hints": [],
|
|
"setup_commands": [],
|
|
"default_namespace": "default",
|
|
"teardown_commands": []
|
|
}
|