Version Control with GitHub

Commits are save points, branches are safe sandboxes, and GitHub is the shared home your deploys plug into.

Building with AI · Lesson 26 · 11 min read

You’ve built something that works on your laptop. Now you want to: not lose it, make changes without breaking the working version, let a friend collaborate, and deploy it to the web. Naming folders “project_final”, “project_final_v2”, “project_final_REAL” doesn’t scale, and one bad edit can wipe out hours of work. Git and GitHub solve all four of these at once — and they’re the backbone of shipping.

Git: a time machine for your code

Git records the history of your project on your own machine. You make changes and then commit them — a commit is a labeled snapshot (“Add dark mode toggle”) you can always return to. The history lets you see exactly what changed and revert to any earlier point. Branches let you work on a change in isolation — on a add-dark-mode branch your experiments never touch the working version — and when it’s ready you merge it back in. Mess up? The main version was never in danger.

GitHub: the shared home for your repo

GitHub hosts your repository in the cloud (the remote). You push your commits there to back them up and share them; others (or future you on another machine) clone or pull to get them. The collaboration centerpiece is the pull request (PR): you propose your branch’s changes, a teammate reviews them, you discuss and adjust, and then they’re merged — a built-in review gate before anything lands. Issues track bugs and to-dos. It’s the difference between code trapped on one laptop and code a team can build on safely.

Why it’s the hub for shipping

Version control isn’t bureaucracy — it’s what makes shipping safe and reversible, and it’s the hub the rest of the stack plugs into. Deploy platforms (like Vercel, next lessons) connect to your GitHub repo and ship automatically on every push to main; automated checks (CI) can run your typecheck and tests on each PR before it merges. Start simple: commit often with clear messages, use one branch per change, and open a PR to merge. The advanced features can wait — these basics already give you a safety net most beginners are missing.

An everyday analogy

Git is video-game save points. A commit is a save you can always reload, so a wrong turn never costs you the whole run. A branch is a separate save file where you try a risky strategy without endangering your main progress — and if it works out, you merge it back. GitHub is the cloud save: it backs everything up off your machine and lets friends load the same file to play alongside you.

Worked example

A normal change, end to end:
1. Create a branch: add-dark-mode (your safe sandbox).
2. Make the change; commit it with the message “Add dark mode toggle”.
3. Push the branch to GitHub.
4. Open a pull request; a teammate reviews, leaves a comment, you fix it and commit again.
5. Merge the PR into main.
6. Your deploy platform sees the push to main and ships it — the feature is live.
If it turns out broken, you revert that commit and you’re instantly back to the version that worked.

This is the reading. The interactive version — active-recall quiz, a hands-on experiment you run in your own AI, and an earned mastery check — is free in the app.

Start this lesson free →

← The Builder's Stack Frontend for AI Apps →