Most students who "use Git" are actually using a button. They click "commit" in a GUI, something happens, and when something breaks they panic — because the model is invisible. The playground exists to make the invisible visible.
git add, they see the file physically move from one panel to the next. When they git commit, the staging panel empties into the commit graph.git push copies commits across the gap and that pushing isn't magic — it's a sync.The playground does not require a GitHub account or installed Git. That's the point. After this class, when they install Git for real, the model is already in their head and the commands feel familiar.
Treat this as a guideline, not a script. The interesting moments are when a student asks a question that derails the plan; the timing has slack for that.
| Min | What you do | What students do |
|---|---|---|
| 0–5 | Tour the screen on projector. Point at the four zones: top bar, story panel with Octo, two columns, terminal. Don't run anything yet. | Open the playground. Look. Don't type yet. |
| 5–10 | Drive Chapter 1 (init + first file) on screen with them following along. Ask "what color is README right now? why?" | Mirror your moves. Notice the red "untracked" chip. |
| 10–18 | Step back. Let them do Chapter 2 in pairs. Walk the room. This is the key chapter. | Type git add and watch the chip turn yellow. Type git commit and watch it turn green and a dot appear in the graph. |
| 18–23 | Stop the room. "Look at the right side. It's empty. What does that mean?" Drive Ch 3 together. | Add the remote, push, watch the right side fill up. |
| 23–30 | Pairs do Ch 4 (branches). Watch for confusion when they checkout main and the file disappears. |
Make a branch, commit on it, switch back, see the file vanish, merge, see it return. |
| 30–37 | Drive Ch 5 together. Connect to real life: "gh pr create is the GitHub CLI — the same command real engineers use. On github.com it's the 'New Pull Request' button." |
Push a branch, open a PR, see it appear on the right, merge it. |
| 37–44 | Ch 6 (conflicts) together. Tell them: "I want you to break it. Conflicts are not failure — they are Git telling you 'two humans had different ideas, you decide.'" | Riley (the simulated teammate) pushes a conflicting change automatically when the lesson hits that beat. Watch the conflict markers appear in the file. |
| 44–50 | Sandbox + wrap. Show one real github.com page. "That commit history? You just made one." Exit ticket (see §7). | Mess around in the sandbox. Try to break something on purpose. |
Each chapter below has: the concept, what to say out loud, what to watch for, and the moment that lands.
The concept: there are four regions on screen and they each mean something specific.
Say: "I'm not going to tell you what Git is yet. Look at the layout. The split tells you something — your computer on the left, GitHub on the right. We're going to fill both sides up over the next 50 minutes."
Watch for: students who already touch the terminal. Stop them. The tour matters.
Lands when: a student says "oh, the staging thing is a separate panel?" — yes, exactly, that's the whole insight of the lesson.
The concept: git init doesn't create files. It tells Git to start watching a folder.
Say: "Git wasn't on before init. Watching anything? Nothing. Now watching everything in this folder. You haven't made any files yet — that comes next."
Watch for: students typing git init and expecting something dramatic. The point is that nothing visible happens yet — it's the mental shift.
Lands when: they make README and Octo says "see, RED means tracked-but-not-saved". Pause here. Make sure everyone sees the red chip.
The concept: there are three places a file can live and add/commit move it between them.
Say (BEFORE they type): "I want you to predict what happens before each command. Where will README go when I run git add? Watch for the color change."
Watch for: students racing through. Slow them down. The whole point is the colors changing in sequence: red → yellow → green.
Lands when: someone goes "wait, why two steps?" Excellent question. Answer: "Because in real projects you change ten files but only want to commit three. Staging is your shopping cart."
The concept: your laptop and GitHub are different computers. Git on your laptop and Git on GitHub each have their own copy.
Say: "If your laptop fell in a swimming pool right now, your work is gone. We're about to fix that."
Watch for: the misconception that GitHub is Git. It isn't — GitHub is a hosting service. Git would still work without it. (Optional aside: mention GitLab/Bitbucket exist.)
Lands when: the right column wakes up after remote add and they see commits stream over after push. The visual sync is the lesson.
The concept: a branch is a parallel timeline. Switching branches actually changes the files on your disk.
Say (this is the move): When they checkout main and team.md disappears, point at it. "Wait! Where did the file go?! It didn't get deleted — it doesn't exist on this branch. It's still safe on the other branch."
Watch for: students panicking that they "lost" a file. This is the moment to redirect panic into curiosity. Have them git branch to confirm both branches still exist.
Lands when: they merge and the file reappears. Some will visibly relax. That's the moment.
The concept: a PR is a conversation about a merge before it happens.
Say: "On real teams nobody merges straight to main. You open a PR, your teammates review the diff and leave comments, you update, then someone clicks merge."
Tell them this is real: "gh pr create is the actual GitHub CLI command. On github.com it's the 'New Pull Request' button — same thing. You're learning the muscle real engineers use."
Lands when: they see PR #1 appear on the right with status "open", then click merge and watch it flip to "merged".
The concept: conflicts happen when two humans edited the same line. Git can't pick a winner. You have to.
Say: "Conflicts are the thing students fear most about Git. They are not errors. Git is asking you a question. The screen will shake — that's me trolling. The conflict is fine."
Watch for: students trying to "fix" conflicts by deleting everything. Walk them through the markers: <<< HEAD, ===, >>> branch. Show that those are the two versions side-by-side.
Lands when: they realize the markers are just text in their file that they delete by editing the file. No Git wizardry — just normal editing followed by add + commit.
The concept: reps. Now do it without the rails.
Say: "Try to break it. Make ten branches. Open three PRs. Have Riley push four commits while you push five. The simulator is patient."
Watch for: the strong students — challenge them with prompts: "Can you make a branch that's behind main, then catch up?" "Can you cause a conflict on purpose?"
Lands when: someone laughs because the screen shook. They are no longer afraid of Git. That's the win.
| What they do | What's actually wrong | What to say |
|---|---|---|
Type git commit with no -m "..." |
The simulator requires the message inline. Real Git would open an editor. | "Always pass -m for now. Later you'll learn that real Git opens vim — and you'll learn the most important command in computing: :wq." |
Forget git add before commit |
They expect commit to mean "save everything." | "Remember the shopping cart? You can't checkout an empty cart." |
| Panic when a file disappears after checkout | It's still in the commits — they just switched branches. | "Type git log. The commit is right there. Branches are different views of the same history." |
| Try to delete conflict markers character by character with arrows | They don't realize they can just edit the file like normal. | Demo a clean overwrite: echo "final clean version" > README.md, then git add + git commit. Reinforce that conflict markers are just text in their file. |
Type real terminal commands like cd, mkdir |
The simulator only knows what it knows. | "Type help — that's the supported list. This isn't a real shell." |
Confuse git pull with git push |
The names are too similar. This is a real Git problem too. | "Pull things to you. Push things away. The right column is the away." |
If students leave with these four pictures in their head, the class succeeded — even if they don't remember a single command.
Have students answer one of these on a sticky note or in chat. Pick whichever matches your pedagogy.
git add and git commit to your past self from 50 minutes ago. One sentence."git revert vs git reset.Every command the playground understands, for printing and handing out. The bottom section is simulator-only — those commands have real-world equivalents but aren't real Git.
| Command | What it does |
|---|---|
git init | start tracking this folder |
git status | show what's changed and what's staged |
git add <file> | stage a file (or use . for all) |
git reset <file> | unstage a file |
git commit -m "msg" | save staged changes as a snapshot |
git log | show commit history |
git branch | list branches; git branch <name> creates one |
git checkout <branch> | switch branches (use -b to create + switch) |
git merge <branch> | merge another branch into yours |
git remote add origin <url> | connect to a GitHub repo |
git push origin <branch> | send commits to GitHub |
git pull | fetch and merge from GitHub |
| Command | What it does |
|---|---|
ls | list files in working directory |
cat <file> | show file contents |
echo "txt" > file | write text to a file (replace) |
echo "txt" >> file | append text to a file |
touch <file> | create an empty file |
edit <file> <content> | quick-edit a file (simulator helper) |
rm <file> | delete a file |
clear | clear the terminal |
help | show all commands |
| Command | What it stands in for |
|---|---|
gh pr create [branch] [target] | "New Pull Request" button on github.com (real GitHub CLI command) |
gh pr merge <id> | "Merge pull request" button (real GitHub CLI command) |
gh pr list | the Pull Requests tab |
| Riley (auto) | The simulated teammate edits & pushes automatically during Ch 6. No student command — it just happens when the lesson reaches that beat. Power users can still drive Riley manually with the undocumented collab family. |
The full breakdown lives in the companion Learning Outcomes doc. The headline:
Eight skills. Initialize a real repo · run the save loop reflexively · push to GitHub · read history · branch with intent · pull before push · open a real PR · survive a merge conflict.
Five mental models. Git ≠ GitHub · files live in zones · a commit is a save point · conflicts are questions · git status is the compass.
The honest test. Drop them in a real project on day one and say "make a branch, fix the typo, open a PR." If they can do it without Googling for 20 minutes, you succeeded.
Pair this with the Mastery Assessment for performance challenges and the Tilt Rubric for spotting fragile understanding under pressure.
Final thought. The single thing students remember from this lesson, years later, is the moment a file changed color when they typed a command. They don't remember syntax. They remember the model. That's the win — they can look up syntax forever, but they can't unsee the model.
Now go teach.
— Octo