Skip to content

1.4 — Saving Your Work (Git Basics)

Git was introduced in 0.2 — The Environment as “Google Docs version history for your entire project.” Now you use it.

You only need three commands for Phase 1. That’s it. Everything else Git can do comes later — in Phase 2, Git Workflow — when you’re collaborating and need branches and pull requests.

CommandWhat It DoesAnalogy
git initStart tracking this folder with GitOpening a new notebook for this project
git add .Mark all current changes as “ready to save”Putting documents on your desk in a “to file” pile
git commit -m "description"Save a snapshot with a label you writeStamping a date and note on the pile, then filing it permanently

Run them in that order, every time you reach a point worth saving:

git add .
git commit -m "add homepage with name and bio"

Every commit is a save point. Like a checkpoint in a video game — you can always go back. You can never lose work that’s been committed. This is your safety net.

The description you write in git commit -m "..." is your commit message. Write it for your future self. “update stuff” is useless. “add contact form to homepage” tells you exactly what changed and why.

TermDefinition
CommitA saved snapshot of your project at a specific moment
Commit messageThe label you write describing what changed and why
StagingMarking which changes should go into the next commit — the git add step
Working directoryThe folder you’re currently in — where your active files live

You might wonder: why do you need git add before git commit? Why not just commit directly?

Staging lets you be selective. If you changed five files but only want to save three of them in this commit, you can git add just those three. For Phase 1, you’ll usually git add . (the dot means “everything”), but knowing staging exists matters when things get more complex.


Next: 1.5 — Putting It Online | Phase overview: Phase 1

Goes deeper in Phase 2: Git Workflow — Branches and Collaboration