🛟Back everything up to GitHub before AI breaks your project · your infinite undo button

When does the need show up? (the exact moment)

The need appears right when you start building a real app with AI — not when you're just chatting with it. At that point the AI touches many files at once, and one day you ask for a small change and, without meaning to, it breaks three things that were working. That's when you find out whether you had a safety net… or not.

And there's a second, subtler brake: the fear of experimenting. Without a net, you ask for timid changes so you don't break anything — and timid changes don't build anything big. With GitHub saved, you go for it: if it goes wrong, you roll back and that's it.

What is Git and what is GitHub? (one sentence each)

Git is the system that saves snapshots of your project over time (each snapshot is called a commit). GitHub is the cloud where you upload those snapshots to keep them safe and to be able to return to any of them. Git lives on your computer; GitHub lives on the internet. Together = backup + time machine.

Where does your project live? Local folder vs sandbox

This is key to understanding why GitHub always pays off, no matter what you build with. AI tools save your project in two ways, and GitHub wins in both:

Local folder — tools like Claude Code work on a folder on your own computer. To see it running you open localhost in your browser. The project is yours and it's on your disk… but if you delete it by accident or a command damages it, without a cloud backup there's no going back.

Its own sandbox — other tools (like NeuralOS, v0, Bolt and similar ones) run your app inside their own environment, and you see it deployed right there, without dealing with folders. Super convenient. But your code lives in that platform's account — if you want a copy that's truly yours and survives no matter what, you put it on GitHub.

The no-terminal path · GitHub Desktop (recommended to start)

If the word "terminal" makes you groan, this is your path. GitHub Desktop is GitHub's official, free app: it does everything with buttons. You see the list of your changes, write a note, and save — without a single command. Its own tagline says it: "focus on what matters instead of fighting with Git."

From there, every time the app shows you changes, you write a short note at the bottom left (the Summary), hit Commit to main, and then Push origin. That's a save point uploaded to the cloud. Do it every time something works well.

The command path · 4 that are worth gold

If you prefer the terminal (or your AI uses it for you), these four commands give you 90% of what you need. Your AI knows them by heart — you can ask it to run them and explain each one.

git init
git add .
git commit -m "first save point: the project works"

git status

git add .
git commit -m "describe in a few words what you got working"

git push

The key moment · rolling back when the AI broke something

Here's the superpower. Imagine your app was working, you asked for a change, and now it's broken. If you saved a point when it worked, recovering it is trivial. In GitHub Desktop: History menu, right-click the good point → Revert changes. With a command, you have two ways depending on what you want:

git revert HEAD

That git revert is the safest: it doesn't delete history, it just creates a new point that undoes the last one. If you only want to recover one file as it was at an earlier point, you ask your AI: "give me back file X as it was in the last commit that worked" and it'll use git checkout. The golden rule:

Branches · try wild ideas without fear (optional but magical)

A branch is a parallel copy of your project where you can experiment without touching the version that works. Want the AI to try something risky? You create a branch, it tries it there, and if it goes well you join it in (merge); if it goes badly, you delete it and nothing happened. Your main version was never in danger.

git checkout -b prueba-arriesgada

The most important part · the 5 moments you ALWAYS save

Here's the real secret, and it's what almost nobody does: GitHub isn't set up once and forgotten. Its value is in the habit. If you don't feed GitHub consistently, the day you need it there'll be nothing to go back to. These are the five moments when saving isn't up for debate — the same ones those of us who build for real use:

Save clean · don't fill GitHub with junk

A good history is one where every point means something. Two simple rules so your GitHub is useful and not a dumpster:

Typical beginner mistakes (and how to avoid them)

The easiest path · let your agent do it through the chat

If you're using a code agent (like Claude Code), almost everything happens through the chat — you don't have to learn commands. Here's what your agent CAN do on its own by message, and the little that's on you:

Ready-to-go prompt · hand it to your AI and everything gets set up

This is the complete prompt, start to finish. Copy it, replace what's in brackets, and paste it to your code agent. It sets up GitHub, connected, and with the habit of reminding you to save.

I want to protect my project with GitHub even though I don't know git. Guide me step by step and do it yourself where you can. My project is called [NAME]; I'm building it with [Claude Code / NeuralOS / another tool].

1) ACCOUNT: if I don't have a GitHub account, tell me exactly how to create it at github.com (free) in short steps.

2) REPOSITORY: tell me how to create a NEW, PRIVATE repository. Suggest a lowercase name with hyphens based on my project's name. If you can create it yourself with my permission, do it; if not, tell me the exact clicks and I'll give you the name or URL.

3) CLEANUP: create a .gitignore that ignores .env, node_modules, temp files and any secrets, so I don't upload junk or passwords.

4) FIRST POINT: initialize git, make the first commit with a clear message, and connect it and push it to my private repository.

5) HABIT: from now on, every time we get something working, BEFORE a big change, and after reviewing/fixing bugs, remind me to save a point and ask me whether to push it to the cloud. Use clear commit messages that my future self will understand.

6) RESCUE: if something breaks, help me go back to the last point that worked without losing my work, and explain in one sentence what happened.

Keep it simple. If there's something only I can do via the web, tell me with the exact clicks.

The official tool (free and verified)