Ship and explain the focused Git commit

A shippable lab artifact includes: how to run it, the metric result (git diff --cached --name-only shows only train.py before commit), the failure you can still reproduce (accidentally staging both files, or committing from the wrong directory), the security gate for staging a .env or credentials file beside the evaluation change, and a rollback note. The user decision it supports remains: land only the tested train.py evaluation change while README edits stay unstaged.

printf 'proved: focused train.py commit\nunproved: remote review\nrollback: git revert HEAD\n'

Expected evidence: git ship note. Store this beside the fixture version so scores remain meaningful after content changes in git-basics.

State operating limits for the focused Git commit in plain language: fixture size, offline vs live dependencies, and what would require a new eval set. Shipping git-basics is honest scoping, not maximal confidence language.

Fill this table in your notes for the focused Git commit:

• Proved on repo with dirty train.py (eval) and README.md (docs): …
• Unproved beyond the fixture: …
• Metric that blocks release: git diff --cached --name-only shows only train.py before commit
• Failure still reproducible: accidentally staging both files, or committing from the wrong directory
• Security gate: staging a .env or credentials file beside the evaluation change
• Rollback: …

Ship the narrative only when the unproved list is honest. Reviewers trust narrow claims that support land only the tested train.py evaluation change while README edits stay unstaged more than maximal language that collapses under the first production oddity.

Hand your ship note to a peer and ask them to recreate a proved/unproved ship note with rollback without watching you type. If they cannot, your evidence is still tribal knowledge. Tighten the run command and the metric line until a stranger can validate the focused Git commit against repo with dirty train.py (eval) and README.md (docs).

At the mastery and shipping 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 proved/unproved ship note with rollback 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

Previous