Don't Lose Your Work — Folders, Git, and Checkpoints

The most demoralizing beginner failure is not a bug. It is losing work.

The AI rewrote too much. You deleted the wrong thing. A package update broke the project. You asked for "cleanup" and got destruction. Or your laptop crashed and the only copy lived in one local folder with no history.

You do not need advanced Git for day one. You do need a minimum safety net.

If you have never heard of Git, here is the one-sentence version: Git is a tool that remembers every saved version of your project, so you can always go back to a point where things worked. GitHub is a website that stores a backup copy of that history online. Together, they are your undo button.

You do not need to master either one right now. You just need to set them up -- and your AI agent can walk you through that in about two minutes.

Why this matters

Beginners stay calm when they know they can go back.

That is why source control matters so much in vibe coding. AI is fast. It can create progress quickly, but it can also create damage quickly. One bad prompt can rewrite your working config, break your database connection, or overwrite the file where your feature actually worked. Without a checkpoint, your only option is to try to remember what the code looked like before -- and memory is not source control.

A checkpoint turns "this got weird" from a disaster into a normal Tuesday.

The minimum safe setup

For your first project, do these things:

create a real project folder
initialize Git
create a remote backup on GitHub
keep secrets out of the repo
checkpoint after every meaningful win

That is enough to start safely.

What a checkpoint actually is

A checkpoint is just a known-good save point you can return to.

In beginner terms, that usually means:

the app still runs
the last small feature works
you understand what changed
you commit before asking for the next risky thing

You are not trying to produce perfect Git history yet. You are trying to make recovery normal.

If you are using a browser builder, the equivalent is still a named version you can roll back to. If you are using an editor like Cursor, it usually means a real Git commit plus a remote push. Different tools, same principle: never let the only good version of your work live in your memory.

If recovery feels awkward, your setup is still too fragile for comfortable iteration.

The four things that matter early

The project folder

Give your project a dedicated folder on your computer. Do not scatter files across Downloads or Desktop. When the AI agent creates files, you want them all in one predictable place.

The `.git` history

When you "initialize Git" in your project folder, it starts tracking changes. Every time you save a checkpoint (called a "commit"), Git remembers exactly what your project looked like at that moment. Think of it as a timeline you can rewind.

The remote repo

A remote repo is your project's backup copy on GitHub. If your laptop dies, your work survives. If something goes wrong locally, you have a clean copy to restore from. Setting one up takes a couple of minutes -- ask your AI agent to help if you have not done it before.

The `.env` boundary

A .env file is where you store secrets like API keys and passwords. The critical rule: never let Git track your .env file. If it gets committed and pushed to GitHub, those secrets become visible to anyone who can see the repo. Your .gitignore file (which tells Git what to skip) should list .env before you ever put a secret there.

Your beginner recovery plan

When something goes wrong:

stop asking the AI for more changes
inspect what changed
decide whether to keep, revert, or go back to the last checkpoint

That is much easier when checkpoints are frequent.

A simple beginner rhythm

Use a rhythm like this:

create project
get it to a known-good starting state
commit
add one tiny feature
test
commit
ask for the next tiny feature

That alone will save you a huge amount of pain.

Try this now

Create a dedicated folder for your first tiny project.
Initialize a Git repository in it and create a remote backup on GitHub. If you are not sure how, paste the prompt below into your AI agent -- it will walk you through the steps.
Add a .gitignore if one does not exist, and make sure .env is listed in it before you ever put secrets there.
Make your first commit (your first saved checkpoint) before the project gets interesting.

Prompt to give your agent

"I am a beginner and I want the safest possible project setup before I keep building. Help me:

confirm this project has the minimum Git safety setup

check that .env-style secret files are ignored

tell me what files should and should not be committed right now

suggest the next safe checkpoint

Do not rewrite history, force push, or delete files unless I explicitly approve it."

What you must review yourself

Whether the repo exists locally and remotely
Whether .env or other secret files are ignored before you store credentials
Whether your last checkpoint is actually a working state
Whether you know how to get back to the last good version if the next AI change goes bad

Common mistakes to avoid

Working without checkpoints for too long. The longer you wait, the harder recovery becomes.
Assuming GitHub alone keeps you safe. Safety comes from meaningful commits, not just a remote repo existing.
Committing secrets because it is "just a test project." Test projects leak too.
Letting the AI do destructive Git operations casually. History-changing commands deserve human approval every time.

Key takeaways

You do not need advanced Git to be safe, but you do need checkpoints
A remote repo is both backup and recovery insurance
.env boundaries matter from day one
Safe beginners commit working states early and often

What's next

Now you have a target and a safety net. Next, run your first real agent session the right way: plan first, one task at a time, and no mystery changes.

Use the lesson prompt before you improvise