LEARNING OUTCOMES

What students
should walk away with

eight skills, five mental models, one honest test
The playground is the practice. This is the destination. After completing the lesson and one transfer assignment, students should be able to do these eight things on a real machine, hold these five mental models, and pass the honest test below.

1The eight skills

If a student can do all eight without help, they're ready for a real team project. The first four are the floor. The last four are the bar.

Solo workflow — the floor
1

Initialize a real repo

Install Git on their machine, run git init in a folder, and explain in plain language what the hidden .git folder is for. Not "magic" — "Git's notebook for this project."
2

Run the save loop without prompting

Edit → git status → git add → git commit -m "...", with a message that names the change. Not "stuff" or "asdf". They should reach for status reflexively, before doing anything else.
3

Get a project onto GitHub

Create a repo on github.com, connect it as a remote, push commits, and verify the same history shows in two places — laptop and browser tab. They should be able to articulate that those are two different computers.
4

Read their own history

Run git log, identify a specific commit, and read what each line means (hash, author, date, message). Optional: git log --oneline for a cleaner view.
Collaboration — the bar
5

Branch with intent

Create a feature branch with a meaningful name, work on it, switch back to main, merge cleanly. Crucially: not panic when files appear and disappear during checkout — they understand branches are different file states, not metadata.
6

Pull before push, every time

Begin a session with git pull, end it with git push. Articulate why that order matters — pulling first prevents avoidable conflicts. This is a habit, not a fact.
7

Open a real Pull Request

Push a feature branch, click "New PR" on github.com, write a description, merge it. The simulator's gh pr create / gh pr merge are the real GitHub CLI commands — students who type them here are already practicing the real muscle.
8

Survive a merge conflict

When Git says "CONFLICT," they don't delete the file or close the laptop. They open it, find the <<<<<<< markers, edit to the version they want, add, commit, move on. They treat conflicts as questions, not errors.

2The five mental models

More important than the commands. If a student forgets every command but keeps these models, they can re-derive the syntax with one Google search.

🖥️
Git ≠ GitHub.
Git is on your laptop. GitHub is a website. They could each exist without the other.
📦
Files live in zones.
Working dir → staging → commits → remote. Every command is a verb that moves files between zones.
💾
A commit is a save point.
Permanent, recoverable, named. Like in a video game — you can always come back.
❓
Conflicts are questions.
Git can't pick which version is right. It's asking you. You answer by editing the file.
🧭
git status is the compass.
When in doubt, run it. It tells you where every file is and what to do next.

3What they explicitly don't need yet

Don't oversell. Trying to teach these now poisons the well — students lose confidence in the basics they do know. These are second-semester topics.

4The honest test

Drop them in a real project on day one.

A teammate (or you, role-playing) says: "Make a branch, fix the typo in README, open a PR."

If they can do that — start to finish, on a real machine, against a real GitHub repo — without Googling for 20 minutes, the playground worked.

If they can't, find the gap. It's almost always one of these three: (a) they don't have Git installed locally; (b) they don't realize their laptop and GitHub are different; (c) git status never became reflex.

💬
They should leave able to do small real things, not big imaginary ones. A student who can confidently make one commit and push it has more practical Git ability than one who's read three chapters of Pro Git.

— Octo