Manage your code with Git: a beginner's start

Why you need Git

Without Git, you're just hoping you "still remember what it looked like before you broke it." Git is a save point and time machine for your code: every save (commit) leaves a moment you can return to, so you can change boldly — if it breaks, roll back to the last working version. It's also the foundation for syncing to the cloud and collaborating.

Four actions are enough

Beginners don't need all of Git — start with these four in plain terms:

• add (pick what to save): choose the changes to record this time.
• commit (save): store the picked changes as a moment, with a one-line note.
• push (upload): sync your local saves to the cloud (e.g. GitHub) — that's your backup.
• pull (download): bring cloud updates back locally — for collaborating or switching machines.

The daily loop is: change a little → add → commit → (when ready) push.

How to write a commit message

Say in one sentence what you did, in the imperative, focused on one thing — e.g. "fix typo on the login page," "add a contact form." One commit, one thing, so when something breaks later it's easy to pinpoint which change caused it.

Rolling back when things go wrong

This is where Git earns its keep: when you break something, or the AI scrambles your code, you can return to the clean state of the last commit. Build the habit of committing after each small piece, so there's always a recent save point to return to.

Common traps

• Committing a secret: a key in Git history counts as leaked (see secrets 101). Use .gitignore to keep out .env and friends.
• Cramming too much into one commit: ten changes in one commit is hard to untangle when something breaks. Commit in small steps.
• Saving locally but never pushing: if the machine dies, it's all gone. Pushing to the cloud is your backup.

Next steps

• Then ship the code: Deploy to Cloudflare Pages
• Keep keys out of commits: secrets 101