Stop Copying Your Project Folder: Git Is the Save Button You Already Have

A confession from this kitchen's early days. The workflow used to look like this: finish a feature that works — immediately copy the entire project folder, just in case. Try something risky in the copy. If it worked, great, the copy becomes the real one. If it broke? Delete the whole folder and start over from the backup.

You know the crime scene: my-app, my-app-backup, my-app-final, my-app-final2, my-app-final-REAL. Every folder a monument to fear.

If that's you right now — no shame, it was us — this recipe ends the ritual today. The tool is Git, it's already on your machine if you've installed any coding agent, and here's the part nobody tells beginners: you don't have to memorize it, because your agent speaks fluent Git. You just need the mental model.

The mental model: save slots for your project

Forget "version control system." Git is a save system, like in a video game:

• A commit is a save slot. It captures your entire project at one moment — every file, frozen. Cost: a few kilobytes and one second. (Your folder-copy did the same job at 500MB a pop.)
• The log is your list of save slots, each with a note ("boss defeated" / "login form works").
• Restore is loading a save. Broke everything at 3pm? Load the 1pm slot. Nothing is ever "ruined" again — the worst case is always back to the last save.
• A branch is a parallel universe. Want to try a risky redesign? Branch off, experiment freely, and either merge the universe back in (it worked!) or abandon it (it didn't — and your main timeline never knew).

That's the whole model. Your folder-copy ritual, translated:

The old ritual	The Git way	What it costs
Copy folder "just in case"	git commit	1 second, ~KBs
final, final2, final-REAL	git log — named, dated history	0 folders
Try risky thing in the copy	git switch -c experiment (a branch)	instant
Failed → delete everything, restore backup	git restore / switch back	2 seconds, nothing lost

The seven commands (the 20% that does 95%)

Even though your agent will run these for you, you should be able to read what's happening:

git init                  # start tracking this folder (once per project)
git status                # what changed since the last save?
git add -A                # stage everything...
git commit -m "note"      # ...and save. THE command. Use constantly.
git log --oneline         # list your save slots
git restore .             # discard changes since last save (careful!)
git switch -c experiment  # open a parallel universe

One setup detail worth knowing: a file called .gitignore tells Git what not to track (dependency folders, secret keys, .env files). Your agent will write a sensible one — the important thing is knowing it exists, because API keys must never go into commits.

And when you're ready for off-machine backup: GitHub is a free parking lot for your repository — git push sends your saves to the cloud. That's a future recipe; local Git alone already kills the folder ritual.

The vibe coder's cheat code: plain-English Git

Here's why this recipe belongs in an AI kitchen. You run Claude Code (or Codex, or Antigravity) — which means you have a Git expert on staff already. These all work, verbatim:

• "Commit my progress with a sensible message."
• "What changed since the last commit?"
• "This approach failed — take me back to the last working state."
• "Make a branch and try the redesign there, so we can throw it away if it's ugly."

We run this exact setup: every post, every design change, every experiment on this site is a commit. When our AI design audit shipped changes readers might hate, we could honestly say "if you vote no, we'll roll it back — that's what version control is for." That sentence is only possible with Git.

The one habit that makes it all work: commit every time something works. Not once a day — every working state. Tasted the dish, it's good? Snapshot. It's the same instinct as your old folder-copy, minus the fear, the gigabytes, and the final-final2 shame.

(Two safety notes, learned the hard way: commits protect you from yourself and your agent — a wrong git restore . throws away uncommitted work, so save before experimenting, not after. And if you gave your agent broad permissions, frequent commits are exactly what makes that trade safe.)

Order up

Paste this into your agent, inside any project you care about:

Set up version control for this project:

1. git init if needed, plus a sensible .gitignore for this stack — make sure
   secrets and dependency folders are excluded.
2. Make a first commit of the current state.
3. From now on, work in save points: whenever we reach a working state, commit
   with a one-line message that says what changed in plain language.
4. When I say "save point", commit. When I say "go back", show me the recent
   commits and restore the one I pick.
5. Never run a destructive command (restore/reset/clean) without first showing
   me exactly what would be lost.

Then explain, in two sentences, where my project's history now lives.

Delete your -backup folders tonight — all of them. You have save slots now, and the fear they were protecting you from doesn't exist anymore.