In a monorepo, how to commit only what you want — leaving WIP in sibling folders untouched. Plus how to see version history for a single subfolder.
Beginners usually think git has two places: your files on disk and commits. Actually there are three:
git addThis middle lane is the staging area (a.k.a. "the index"). It exists so you can pick which changes go into the next commit. When you run git add <path>, you're moving stuff from working → staging. When you run git commit, you take whatever's in staging and stamp it into history.
Here's the exact scenario you asked about: you're working in games/duck-hunt/, you're done with a clean change there, but you also have WIP changes in games/pepper-popper/ that you're not ready to share. How do you push just duck-hunt?
The WIP in pepper-popper/ and portal/ stays untouched on your Mac — uncommitted, unpushed, untouched. Only the duck-hunt changes go live.
git add . means "stage everything that's changed." Useful when you ARE ready to commit it all. git add <specific-path> is the surgical version. Get comfortable with the surgical one — it's the difference between "I accidentally committed my half-finished side-quest" and "clean commit history."
git status tells you everything: what's modified, what's staged, what's untracked. It's the most-run command in any seasoned dev's life. Run it before git add, after git add, before git commit. It's free to run, never destructive, always informative.
git diff shows what actually changed inside the modified files. Run it when you're not sure what you edited. git diff --staged shows what's in the staging area (about to commit). Together with git status, these are your three eyes.
You asked whether playground's top-level portal could show its own version history independent of the sub-games. Yes — git can show you the commit history of any path, not just the whole repo. The history is one continuous stream, but git lets you filter it by directory:
The -- (two dashes alone) separates "git args" from "path filters." Anything after it is a filesystem path or glob pattern.
Want playground's portal to show "what sub-game just got updated"? Run git log -5 --pretty=format:"%h %s" -- games/ as part of your build step, write the output into a JSON file, and have the portal's HTML read it. Build-time generation. No runtime database needed.
A tag is a stickier sticky-note than a branch — it points at a specific commit and doesn't move. Devs use tags to mark releases: v1.0, v1.1, etc.
In a monorepo, you can prefix tags with subfolder names so each game's release history stays distinct:
Tags are useful when you want to say "duck-hunt is at version 1.2" or roll back to a specific past state. For experimental playground stuff, you may never need them. Pull tags out of the toolbox when you genuinely have releases to mark — not before.
From Lesson 3 you know about pinned repos, topic tags, the lovebuilt org, and archiving. There's one more pattern worth introducing: the catalog README.
The idea: one of your repos is explicitly the "table of contents" for the rest. Its README links to every other project of yours, organized by category, with short descriptions and live URLs. You make this the pinned-first repo on your GitHub profile. Visitors land there and orient themselves before drilling in.
If your catalog repo is named lovebuilt (matching your username/org), GitHub shows its README on your profile page. Make a beautifully-formatted catalog and it becomes your public-facing developer homepage. Free. Zero hosting. Always up to date with your actual work.
git add moves working → staging. git commit moves staging → history.git add games/duck-hunt/ leaves sibling WIP completely aloneduck-hunt/v1.0).