Course B · Module B1 Production · Lesson 1 of 18

GitHub & Worktrees

Never fear breaking your app again — you'll have save points, full undo history, and a way to work on two things at once.

~13 min · Have your Course A project open · Prereq: A17 Capstone A

At the end of Course A you shipped something real — and then probably held your breath every time the AI rewrote a file. That fear is rational: one wrong change and the app stops working, and you have no clean copy to go back to. That ends here. Your single win in this lesson: by the end you'll understand Git and GitHub well enough to always have a safe way back, and to experiment freely knowing nothing is ever permanently broken.

Git: automatic save points for your project

Think of a video game with unlimited manual saves. Every time you reach a good checkpoint, you hit Save. If the next dungeon kills you, you reload — you never lose the whole run. Git is that for your code.

Each save is called a commit. A commit is a labeled snapshot: "working homepage," "added contact form," "payment flow done." Your full project history is a stack of these snapshots going back to day one. You can jump back to any of them in seconds.

✓ What a commit gives you

  • A permanent record of every change, who made it, and when
  • One-command undo — roll back to any earlier snapshot
  • A message in plain English ("fixed broken checkout button")
  • Proof of what the app looked like before the AI rewrote things

✗ Without commits

  • One bad AI change can destroy hours of work
  • No record of what changed or why
  • The only undo is Ctrl-Z — until you close the file
  • Collaborating means emailing zip files and praying

Branches: safe copies to try something new

Imagine you want to redesign your homepage — but you're not sure it'll work, and you don't want to wreck the version your customers see right now. A branch solves this exactly.

A branch is a parallel copy of your project. You make one, experiment freely on it, and when you're happy you merge it back into the main copy. If the experiment fails, you delete the branch and your main copy is completely untouched. The AI can suggest "create a branch called new-homepage" and do it for you — you just need to know why it matters.

The rule of thumb: any time you're about to try something new or the AI is about to do a big rewrite, make a branch first. It takes about five seconds and costs you nothing except peace of mind — which is worth everything.

GitHub: the cloud home for your project

Git lives on your computer. GitHub is where your project lives on the internet — a permanent, backed-up, shareable copy. Think of it as Dropbox for code, except it understands every commit and branch in your history.

When your AI coding tool (Cursor, Replit, v0, Lovable, etc.) says "push to GitHub," it is uploading your latest commits to that cloud home. Benefits you get automatically:

BackupEven if your laptop dies, your project is safe in the cloud.
HistoryEvery commit you ever made is stored, searchable, and restorable.
SharingA contractor or AI tool can see your code without you emailing files.
DeployPlatforms like Vercel watch your GitHub repo and auto-publish when you push.

Worktrees: two things at once, no confusion

Here's a problem you'll hit as your app grows: you're in the middle of building a new feature, but a bug just broke something for customers and you need to fix it right now — without losing all your half-finished feature work.

The standard answer is to stash your work, switch branches, fix the bug, switch back, and unstash. That's fiddly. A worktree is a better answer: it lets Git check out a second branch into a second folder on your computer, so both branches exist as live folders simultaneously. You fix the bug in one folder, ship it, then walk back to the other folder and carry on with the feature — no juggling, no switching, no lost work.

Your AI tool can set this up for you. Tell it: "Create a worktree for the hotfix branch so I can work on it without losing my feature/signup work." It will run the one-line command. You just need to understand what the two folders represent.

The mental model for worktrees:
  1. Main folder — your feature/signup branch, half-built, safe where it is.
  2. Second folder — your hotfix branch, checked out fresh, ready to edit.
  3. Fix the bug in the second folder. Commit. Push. Deploy.
  4. Walk back to the first folder. Carry on. Nothing was touched.

Check yourself

Answer before opening — recalling it is what makes it stick.

The AI rewrites your checkout page and now nothing works. How do you recover?

Roll back to the last good commit. Because you committed before the rewrite, Git has a labeled snapshot of exactly what was working. You tell the AI "revert to commit X" or check out that commit — the broken version disappears and the good one is restored instantly.

What is the difference between Git and GitHub?

Git is the save-points system that runs on your computer; GitHub is the cloud service where those save points are stored, backed up, and shared. You can use Git entirely offline — but without pushing to GitHub, a lost laptop means lost history.

A customer reports a broken payment button while you're halfway through redesigning the dashboard. What's the worktree move?

Check out the fix as a worktree in a separate folder. Your half-finished dashboard work stays exactly where it is in its folder. You fix the payment bug in the second folder, commit, push, and deploy. Then you walk back to the dashboard folder — nothing changed, nothing lost.

Read this next (primary source)

About GitHub and Git — GitHub Docs. The official plain-English introduction: what Git is, what GitHub adds, and how the two fit together. ~8 min. See RESOURCES.md for more.

I'm your teacher — ask me anything. Not sure where your project's Git history actually is? Not clear on when to make a branch versus just committing? Paste your situation and I'll walk through the exact steps for your specific app and tool. This is the kind of thing that takes two minutes to explain and saves hours of panic later.

New terms from this lesson — commit, branch, repository, deploy — are in the course glossary. Keep it open as you go.