Edit, Commit, Deploy

You have a development environment set up, your project is cloned, dependencies are installed, and the dev server is running. Now it's time to actually change something — and see the full cycle from editing code on your machine to having those changes live on the internet.

This exercise ties together everything you've done so far into a single, repeatable workflow. It's the workflow you'll use for the rest of this course and for anything you build after.

Seeing changes: hot reload

The first step is simple: open a file in your code editor, find some visible text on the website, change it, and save. The moment you hit save, you'll experience hot reload — the browser automatically updates to show your change without you having to manually refresh. This happens because the development server watches your files and rebuilds only what changed. It makes the feedback loop incredibly tight: edit, save, see the result. Instantly.

Terminal shortcuts

This is a good moment to start getting comfortable with a few essential terminal skills. You'll be using the terminal frequently during development, and a few shortcuts will save you a lot of time. Ctrl+C stops any running process (like your dev server) — and on Mac, that's specifically the Control key, not Command. The up and down arrow keys cycle through your previous commands, so you can quickly re-run something like npm run dev without retyping it. And Ctrl+R lets you search through your command history, which is handy when you need a command from a while ago.

Verifying with the build

Once you're happy with your changes in development, you need to verify they'll work in production too. Sometimes code works fine in the development environment but fails when it's built for production. The build process transforms your development code into optimized, production-ready files — compiling TypeScript, bundling modules, minifying CSS and JavaScript, processing images. You trigger this with npm run build. If it succeeds, you know your code will deploy properly. If it fails, the build logs will tell you what went wrong.

Saving changes with Git

After a successful build, it's time to save your changes with Git. This is a three-step process: stage, commit, push.

First, run git status to see which files you've changed. This gives you a summary before you commit anything. Then use git add . to stage all your changes — this tells Git which files you want to include in the next snapshot. Then create a commit with git commit -m "Your message here". A commit is a snapshot of your project at this moment in time, and the message describes what changed.

Writing good commit messages matters. Start with a verb — "Update homepage heading," "Fix typo in about section," "Add contact email to footer." Be specific but concise. This isn't just for you — it's for anyone (or any AI tool) that looks at the project history later. A hardcoded value you changed today might need to become a variable tomorrow, and a clear commit history helps you trace what happened.

Once committed, your changes are saved locally but GitHub doesn't know about them yet. Pushing uploads your commits to the remote repository on GitHub. Run git push, and your code travels from your machine to the cloud.

Automatic deployment

And then the magic happens. Vercel is watching your GitHub repository. The moment you push, it detects the change, pulls your code, runs npm run build on its servers, and deploys the result. Within a minute or two, your changes are live on the internet. Visit your production URL and there they are.

The complete workflow

This is the complete workflow:

1. Make changes locally (with npm run dev running)
2. Verify the build works (npm run build)
3. Check what changed (git status)
4. Stage your changes (git add .)
5. Commit with a message (git commit -m "message")
6. Push to GitHub (git push)
7. Vercel automatically deploys
8. Check your live site

This cycle repeats for every change you make. It might feel like a lot of steps right now, but it quickly becomes muscle memory. And it's important to understand each step because this is exactly the same workflow that AI tools follow. When an AI agent makes changes to your code, it's doing the same thing: editing files, running builds, committing, and pushing. If you understand the workflow, you understand what the AI is doing — and you'll know when something goes wrong.

Working with AI in your editor

One more thing worth knowing: your code editor likely has AI features built in. Tools like Cursor can suggest edits, explain code, and generate boilerplate. Feel free to experiment with these, but always review what the AI produces before accepting it. Understanding what changed and why is the whole point of this exercise — and of this course.