Frame the focused Git commit experiment

Success is not “I followed the tutorial.” Success is producing evidence that: git show --stat on HEAD lists train.py but not README.md. The accepted input is narrow on purpose: working-tree edits to train.py and README.md in a local repo. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: git status and git diff before any add. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

git status --short
printf 'goal: commit only train.py evaluation change\n'

Expected evidence: short status of dirty files. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the focused commit for evaluation-script change, a decorative win often looks like a clean run that never checks git diff --cached --name-only shows only train.py before commit. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: staging a .env or credentials file beside the evaluation change.

For git-basics, write the claim on a sticky note in this exact shape: “Given working-tree edits to train.py and README.md in a local repo, the focused Git commit will …”. Fill the ellipsis with the observable part of: git show --stat on HEAD lists train.py but not README.md. Tape the baseline beside it: git status and git diff before any add. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to land only the tested train.py evaluation change while README edits stay unstaged. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (repo with dirty train.py (eval) and README.md (docs)) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against repo with dirty train.py (eval) and README.md (docs). Note the metric you will eventually require (git diff --cached --name-only shows only train.py before commit) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is accidentally staging both files, or committing from the wrong directory.

At the experiment brief stage for git-basics, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about repo with dirty train.py (eval) and README.md (docs) that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: git status and git diff before any add.

For this page specifically, success looks like a falsifiable claim and baseline written before coding while still centering the user decision to land only the tested train.py evaluation change while README edits stay unstaged. If you cannot point to a file, command, or assertion that proves that for the focused Git commit, stay on this page instead of advancing.

Git glossary

Next