Git is version control — a system that tracks every change you make to your code, lets you go back to any previous version, and lets multiple people work on the same project without overwriting each other.
The part most people actually use every day is three commands: git add, git commit, and git push. That's the loop. Once it's automatic, you stop thinking about it — you just do it.
What it does: Stages all the files you've changed — tells git "I want to include these changes in my next save."
Think of it like putting papers in an envelope. You're selecting what goes in before you seal it.
The . means "everything I changed in this folder." You can also add specific files: git add index.html
What it does: Saves a snapshot of your staged changes with a description. This is the actual record in your project's history.
Think of it like sealing the envelope and writing on the front what's inside. The message is what you'll read later when you're trying to remember what you changed.
Write commit messages that describe what changed and why, not just "update" or "fix." Future you — and Claude — will thank you.
What it does: Uploads your committed changes to GitHub. This is what makes them visible to the world, to your collaborators, and to Vercel (which then auto-deploys).
Think of it like mailing the envelope. Until you push, your commits only exist on your computer.
Every time you finish a meaningful chunk of work — added a feature, fixed a bug, updated copy — run the three commands in order:
git add . git commit -m "Add contact form to homepage" git push
That's it. Your changes are saved, recorded, and live on GitHub. If you've connected Vercel, your site updates automatically in the next 30 seconds.
How often should you commit? More often than you think. A commit is not a "done" marker — it's a checkpoint. Think: "If I had to undo the last 20 minutes of work, would that hurt?" If yes, commit now. Most people working with AI-assisted code commit every 15–30 minutes.
Before running git add, it's useful to see exactly what changed:
# See which files changed git status # See the exact lines that changed git diff
git status lists every modified file. git diff shows the before/after for each line. You don't need to use these every time — but they're useful when you want to double-check before committing.
# 1. Check what changed (optional but useful) git status # 2. Stage everything git add . # 3. Save a snapshot with a description git commit -m "Describe what you changed and why" # 4. Upload to GitHub (+ auto-deploy via Vercel) git push
If you committed something you didn't mean to — wrong file, bad message, broken code — don't panic. The point of git is that nothing is permanent.
The easiest fix: just make the correction, add it, and commit again. Most mistakes are easier to fix by moving forward than by trying to undo. If you need to undo a specific commit, ask Claude — give it the context and it will tell you exactly what to run.
The git loop is one of the first things MakerSquare students learn — and within a day, it becomes as automatic as saving a document. By the end of the program, students have committed hundreds of times across three deployed projects.