Git Workflow

So far you've committed straight to main – and for most of what you build, that's exactly right: small changes, shipped continuously. This lesson makes that habit solid, and shows you the one time it's worth doing more: branching to test a big or risky change on a preview before it touches your live site.

Quick vocabulary:

  • main: your always-deployable default branch – push to it and your site updates.
  • commit: a snapshot of your changes with a short message.
  • branch: a safe side workspace for changes you don't want on main yet.
  • preview deployment: a temporary live URL Vercel builds for a branch, so you can test before merging.

1. Clean commits to main (your default)

Good commit history is readable and easy to undo. The standard is Conventional Commits (type(scope): summary) – and Claude writes them for you, matching your repo's style. You just describe what changed.

Commit my changes and push to main
I have changes I want to ship. Please:
1.Review the diff and stage the work in small, logical chunks.
2.Commit each chunk with a clear Conventional Commit message (e.g. feat(contact): add contact form) that matches my repo's recent style.
3.Push to main so it deploys to my live site.
4.Tell me what you committed and confirm the deploy.

Outcome: You shipped a change to your live site with clean, clear commits – all through the chat.

I made clean commits to main and shipped them

2. When to branch: test a risky change on a preview first

Most changes go straight to main. But some are big enough that you'd rather try them on a separate, live preview before they reach your real site – adding login (Level 4) or payments (Level 6) are the classic examples. For those, you build on a branch, test it on a Vercel preview deployment, and only merge to main once it works.

You don't run the git commands yourself – Claude does it. The flow is:

  • Claude creates a branch for the feature.
  • You build and refine it there (same plan → build → preview → iterate loop).
  • Claude pushes the branch → Vercel gives it its own preview URL.
  • You test on that preview. When you're happy, Claude merges it into main and it goes live.
Branch, preview, and merge a bigger feature
I'm about to build a bigger feature and want to test it safely before it hits my live site.
1.Create a branch for this feature and switch to it.
2.We'll build it together on the branch.
3.When I'm ready, push the branch so Vercel creates a preview deployment, and give me the preview URL to test.
4.Once I confirm it works, merge the branch into main so it goes live, and clean up the branch.
Walk me through anything I need to decide.

Outcome: You know how to branch, test on a preview, and merge – the safety net you'll use for auth and payments later.

I know when and how to branch and test on a preview

Summary

  • Default: small, clean commits straight to main – Claude writes the messages, pushing ships them live.
  • For big or risky features: build on a branch, test on a Vercel preview, then merge to main. You'll do exactly this for login and payments in later levels.

References