Files
rootnode-academy/content/root/root-03-git-collaborative-development/m02-git-mental-model/04-guided-exercise-predicting-git-status.md
T
ced4568andClaude Sonnet 5 e68b6f445a 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

1.3 KiB

Guided Exercise: Predict git status Before You See It

This is a paper exercise — commit to a prediction before checking it in the Lab.

Your task

Starting from a clean repository (nothing staged, nothing modified), predict what git status --short would show after EACH of these actions, in sequence:

  1. echo "v1" > file.txt (a brand new file)
  2. git add file.txt
  3. echo "v2" >> file.txt (modifying the ALREADY-STAGED file further)
  4. git commit -m "Add file"

A worked shape to check yourself against

  1. ?? file.txt — untracked, in the working tree only.
  2. A file.txt — staged (left column).
  3. AM file.txt — this is the surprising one: staged (A, left column) AND modified again since staging (M, right column) — the staging area has a SNAPSHOT from step 2, and your further edit in step 3 hasn't been staged yet.
  4. Clean (nothing) — but only the STAGED version (from step 2, without the step-3 edit) actually got committed; the step-3 edit remains as an uncommitted modification afterward.

Instructor Notes

Facilitation: Item 3 is deliberately the hardest — it's the exact scenario that surprises real beginners ("I thought I already staged this file, why does it show changes again?"). Worth slowing down on.

Approximate timing: 10-12 minutes live discussion; 8 minutes self-paced.