GitHub 101
The place your code lives online — and the source of truth your live site is built from. Five minutes to the mental model.
What GitHub actually is
Two things wearing one name. Gitis a save system for code: every “commit” is a save point you can go back to, like version history in Google Docs — but for your whole project folder. GitHub is the website that keeps a cloud copy of those save points.
💡 tipPeople say “git” and “GitHub” interchangeably. If you remember one thing: git is the save system, GitHub is where the saves live online.
The four words that matter
The vocabulary
- repo — one project's folder, with its entire history (short for repository)
- commit — a save point with a note — “added focus timer”
- push — upload your new save points to GitHub
- pull — download the latest saves — matters once you work from two machines
💡 tipThat's genuinely all the vocabulary you need to ship. Branches, merges, pull requests — real concepts, but you can build and launch without touching them.
Why you need it even working alone
Three reasons, in order of how much they'll matter to you:
1. Your live site builds from GitHub, not your laptop.Hosts like Vercel watch your repo and rebuild your site from whatever's there. Work that was never pushed simply doesn't exist as far as the internet is concerned.
2. Unlimited undo.Every commit can be restored. “Restore the version from yesterday” is a thing you can literally say to Claude.
3. Your laptop stops being a single point of failure. Spill coffee on it tomorrow — your project is fine.
How you'll actually use it (with Claude Code)
Here's the part nobody tells you: you never type git commands. Claude runs them for you. Your entire GitHub workflow is three prompts:
Push this project to a new GitHub repository called my-app.Commit and push all my changes.Run git status — is all my work committed and pushed to GitHub?💡 tipMake “commit and push all my changes” your end-of-session habit, the way you'd hit save before closing a document. Everything downstream — your live site, your undo history, your backup — flows from pushed work.
Public vs. private repos
Public means anyone can read your code — not edit it, not touch your site. Private means only you. Both are free. For portfolio-type projects, public is fine and plays nicest with free hosting tiers.
🔑The one rule either way:
Never put passwords or API keys directly in your code — public or private. Secrets belong in environment variables. If you're unsure, ask Claude: “are there any secrets in my code that should be env variables?”
The classic gotcha
🩹“It works on my laptop but my live site is old / blank”
Nine times out of ten: your work was never pushed. Your host is faithfully serving the last thing it saw on GitHub. Ask Claude the git status prompt above — if it says “nothing to commit, up to date,” the problem is elsewhere; otherwise, push and you're fixed.