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]>
60 lines
3.1 KiB
Markdown
60 lines
3.1 KiB
Markdown
# 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 log` shows 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.)
|