The session where it stops being a folder
Four sessions of work currently live in one folder on one laptop - one spilled coffee from oblivion. Today that changes twice over: git makes every state of your project recoverable, and GitHub Pages makes the site real, with a URL you can text to your mother. This is also, quietly, the session where you stop fearing git - because Codex drives and explains, and you just have to understand the moves.
Git without the trauma 8 min live
Git has a scary reputation it earned from bad tutorials, not from what you need today. The deal: Codex runs the commands, you understand the moves - init once, ignore the junk, commit with real messages.
LiveThe three moves: init, ignore, commit4 min▶
Everything git does for you this course rests on three moves: init (start tracking this folder), .gitignore (never track junk like .DS_Store or editor files), and commit (save a named snapshot). You don't memorize commands - you supervise them:
- "Explain before running" turns setup into a five-minute git lesson taught on YOUR project - the only kind that sticks.
- Real commit messages: "Personal site: about, showcase, ideas sections with design system" - not "stuff" or "asdf". Future you reads these.
- Commit at every good moment from now on: finished a polish loop? Commit. About to try something risky? Commit first.
LiveReading a diff - the skill that makes git useful2 min▶
A diff is just "what changed since the last snapshot" - lines added, lines removed. You never need to decode raw diff output, because Codex narrates it:
This one sentence makes you the editor of your own history. Nothing enters a commit that you didn't read a summary of - which is exactly the discipline that matters when the stakes grow beyond a personal site.
Self-studyWhat this safety actually buys you2 min read▶
- Every committed state is recoverable. A bad edit, a Codex change you hate, a deleted file - "restore the header to how it was two commits ago" and it's back. Experimentation becomes free.
- History is documentation. Six months from now, "when did I change the accent color and why?" has an answer.
- Git is the bridge to shipping. GitHub Pages (Part 3) serves your site straight from this history - commits aren't just backups, they're deployments-in-waiting.
- The mental model in one line: git is a save button that never overwrites - every save is kept, named, and restorable.
Self-studyThe six git words you'll actually hear2 min read▶
| Word | Plain English | You'll meet it when |
|---|---|---|
| repo | A folder git is tracking - your project plus its whole history | Everywhere, constantly |
| commit | A named snapshot of the project at one moment | Every save point you make today |
| diff | What changed between two snapshots - lines added, lines removed | The pre-commit summary Codex narrates |
| remote | A copy of the repo living elsewhere - for you, on GitHub | Part 3, when your laptop stops being the only copy |
| push | Send your new commits to the remote | The moment your site updates, live |
| branch | A parallel line of history for trying things - yours is called main | Pages deploys from it; teams live in them |
That's the whole vocabulary this course needs. When any other git word appears, ask Codex "explain that like I'm new to git" - it always lands.
The review habit 6 min live
Before changes become history, a second pair of eyes - /review examines your uncommitted changes (or past commits) and catches what you skimmed past: bugs, leftovers, inconsistencies. It slots into the pipeline right before commit.
Live/review before every commit3 min▶
Run /review with uncommitted changes in the folder and Codex reviews them like a colleague would: reading the diff with fresh eyes, against the whole project. What it reliably catches on a site like yours:
- Bugs: a link pointing at a file you renamed, a script referencing an id you deleted.
- Leftovers: the TODO you meant to resolve, the commented-out block, a console.log from debugging.
- Inconsistencies: a hardcoded color that dodges your design system, a footer year that says last year.
It can also review past commits - handy for "did anything sloppy slip into yesterday's work?"
LiveThe same habit at team scale - Codex on GitHub2 min▶
The habit you're building solo is the exact one teams run on GitHub: Codex reviews pull requests there too - mention @codex on a PR to request a review, or it reviews automatically on repos where that's enabled. Same reviewer, same catches, at the scale where a missed leftover costs real money.
GitHub Pages, live 8 min live
GitHub Pages serves a static site straight from a repository - free, no servers, no config files. The recipe: create a repo, push your commits, flip one setting, wait a minute, open your URL.
LiveCreate the repo and push - two roads, one prompt4 min▶
- Public repo: GitHub Pages on a free account needs the repository to be public - fine, it's a website; public is the point.
- The gh CLI road is three commands and stays in the terminal; the web road is clickier but shows you what a repo looks like from GitHub's side. Both end in the same place.
LiveFlip the switch: enable Pages2 min▶
On github.com, in your repo: Settings → Pages → Source: deploy from branch → main, root folder ( / ) → Save. GitHub builds for about a minute, then your site is at https://YOURNAME.github.io/my-site/.
- Not up yet? Give it 60-90 seconds and hard-refresh. The Pages settings panel shows the live URL and build status.
- The update workflow forever after: edit → /review → commit → push → live in about a minute. No redeploy button, no upload step - push IS deploy.
The push-is-deploy loop changes behavior: learners who shipped on Pages kept improving their sites for months, because the distance from "I should fix that typo" to "it's fixed, live" is under two minutes. Friction is what kills side projects - this workflow has almost none.
Self-studyOptional: your own domain2 min read▶
- yourname.com instead of yourname.github.io costs about $10-15/year: buy the domain at any registrar, add a CNAME record pointing to
YOURNAME.github.io, then enter the domain in the repo's Pages settings and tick "Enforce HTTPS". - Codex can walk you through it: "I bought yourname.com at [registrar] - give me the exact DNS records and Pages settings for this repo."
- No rush: the github.io URL is perfectly presentable, and the domain can be added any time without touching the site itself.
Git init, first commit, every command explained ★ 8 min · everyone commits
In your project, run the Part 1 setup prompt: init, .gitignore, first commit - with Codex explaining each command before running it.
Read the explanations out loud with a neighbor. If any line is fog ("what's staging?"), ask Codex - it's the cheapest git tutor alive.
Check the commit message before approving. If it's vague, demand better: "Rewrite that message so future-me knows what this snapshot contains."
Install the diff habit for the rest of the course: "From now on, show me what changed and why before every commit."
Sabotage, then /review ★ 6 min · everyone sabotages
Sabotage your own site, deliberately: hardcode the footer year to 2019, and leave a <!-- TODO: fix this later --> somewhere in index.html.
Run /review. Watch it read your uncommitted changes and catch both plants - usually with a politely raised eyebrow.
Let Codex fix what the review found, then commit clean. Sloppiness in, review, cleanliness out - that's the pipeline you just felt work.
Say the rule together: nothing gets committed without a review. It's 30 seconds. It's the habit.
Push, enable Pages, open YOUR live URL ★ 10 min · everyone ships
Run the go-live prompt from Part 3: create the public repo (gh CLI or web flow), connect, push. Confirm the repo name when Codex asks.
On github.com: Settings → Pages → deploy from branch → main, root → Save. Then watch the build tick for a minute - the longest minute of the course.
Open the URL. Not on your laptop - on your phone. That's your site, on the actual internet, reachable by anyone alive.
Screenshot it. You built and shipped a website. Four sessions ago you were installing a CLI.
This week ◐ 30 min total
- Make one real update through the full loop: edit something on the site → /review → commit → push → watch it go live. The loop has to run once without a safety net of session energy.
- Send the URL to three people. Not "when it's perfect" - now. Their reactions are Session 6 fuel, and perfect never ships.
- Optional: buy the custom domain and wire the CNAME (Part 3 self-study card). Codex handles the DNS spelling.
Three questions before you go 🎯 ◐ 90 seconds
1 · Why run /review BEFORE committing, not after?
Review sits before commit in the pipeline by design - it CAN review past commits too, but the cheap moment to fix a mistake is before it becomes history. Push is deploy, so committed sloppiness goes live.
2 · What does GitHub Pages need from your repo on a free account?
Public repo, Settings → Pages → deploy from branch → main, root ( / ). No servers, no config files - GitHub serves your committed files as-is.
3 · The update workflow for your live site, in order:
Push IS deploy - no upload step, no redeploy button. Which is exactly why the review sits before the commit: whatever you push is what the world sees.
Official sources covered
This session teaches the working content of OpenAI's code review documentation and the CLI's git and review workflows - docs at learn.chatgpt.com and free courses at OpenAI Academy.