Vibe coding with Git: undo mistakes, keep your API keys safe

You ask your AI assistant for one small change to the login page, and it replies “Fixed!” You run the app and it won’t start. You scroll back through two hours of conversation trying to remember what worked, and you realise there is no copy of the version that did. If your project has no history, you can’t go back.

You can build real things with an AI coding assistant without learning to code, and a small number of habits will keep your work safe, your secrets off the internet, and your setup reproducible the next time you open a session with the AI. Which habits are they, and when do you ask your assistant for each one?

The four steps before any new AI-built project:

1. Make a folder. One project, one folder. Don’t build inside your Desktop.
2. Put it under version control on day one, before you’ve written anything worth saving. git init takes six seconds.
3. Add a .gitignore before your first commit. The template further down covers the non-negotiables.
4. Put your API keys in a .env file that’s listed in your .gitignore, never inline in your code.

The AI can run all of these commands for you, and you can ask for each step in plain words: “commit what we’ve got so far before the next change” is a sentence Claude Code or Cursor will understand and carry out. What you need to know is when to ask.

Part 1 of 4 Learn

Git and GitHub in one minute

Before the habits, two quick definitions, because the rest of this guide uses both words and they’re not the same thing.

Git is a program that lives on your computer. It keeps every version of a folder that you save (commit), so you can go back to any of them. Every command in this guide is a Git command.

GitHub is a website. It stores copies of your Git history in the cloud, adds collaboration on top (issues, pull requests), and is where most of the open-source code in the world currently lives. It’s owned by Microsoft, and it’s free for most solo use. Alternatives exist, such as GitLab, Codeberg and Bitbucket, and for what this guide covers they’re interchangeable.

Git is the version-control tool. GitHub is one of several places to park copies of your Git history so it’s not only on your laptop. You use Git locally every day. GitHub is optional but worth it for the off-site backup alone.

Use version control, because the AI can break working code

When you build alone with an AI, nobody else keeps a copy of the code that worked. One confident-sounding “fix” can break it, and the AI won’t always notice.

Building fast with AI has a second cost, which Margaret-Anne Storey describes as cognitive debt: the humans involved may have lost track of what the program is supposed to do and may not understand what the program is supposed to do, how their intentions were implemented, or how to change it. Simon Willison called her piece the best explanation of the term he’d seen so far, and wrote that after prompting whole features into existence without reviewing them, he’d found himself “getting lost in my own projects”. The code runs, you don’t fully understand why, and when it stops running you can’t diagnose it from memory. You need the old version back to compare against.

Version control is how you get the old version back. It’s also how you answer “what did I change between the working one and this broken one?” without retracing the last two hours of conversation with the AI.

You can use Git without GitHub, and “I don’t want to put this on GitHub” is a fine preference. Just know that Git on its own lives on your laptop: if the laptop goes, the history goes with it, so keep an off-site copy somewhere. What you can’t do without is version control itself. Without it, one bad fix can lose the project.

I’ve been relying on backups my whole working life: I’ve pulled from them when I needed to, and lost nothing important because of them. I know they save real work when something breaks. When you get the chance to bake that safety net into the thing you’re building from day one, there’s no good reason not to.

What to do:

• If you’re building anything you’d be upset about losing, put it under version control today.
• Use Git locally at minimum; use GitHub (or GitLab, Codeberg and so on) if you want a backup that’s still there if your laptop breaks.
• Ask your AI: “Put this folder under version control and push it to a private GitHub repo called [name].” It can run every command it needs to.

Commit at good stopping points

Git has dozens of commands, and you only need four to start. The others exist for problems you don’t have yet.

The four moves that cover most solo use:

• git init turns a folder into a Git project. Done once, on day one.
• git add . stages everything you’ve changed.
• git commit -m "what changed" saves a snapshot with a message describing what’s different.
• git push sends your snapshots to GitHub, once the project is connected to a repo there (ask the AI to set that up).

Every time you’ve done a chunk of work and it’s in a good state, run git add . then git commit -m "...". If you’re using GitHub, git push once in a while to back it up.

The coding assistants in the rules-file table further down can run Git commands in your project folder. Ask in one sentence: “Commit what we’ve got and describe the change.” They will do the rest, so you don’t have to type Git commands by hand.

The three times you’ll be glad you set this up:

1. The AI’s “small fix” breaks everything. Start by finding the problem, then decide whether to keep the change:
   • Ask “Show me what changed since the last commit” to see the difference.
   • If you can’t fix it, ask “Undo everything since my last commit, including any new files” and you’re back at the last working snapshot. That throws the changes away for good, so only ask when you don’t want them.
   • If you’d already committed the bad change, ask “Revert my last commit”. Git adds a new commit that reverses the old one (git revert), so nothing is lost.
2. You want to try a risky idea without committing to it. Make a commit, try the idea, keep it if it works, undo it if it doesn’t. There’s no doubt about what the “before” state was.
3. You need to ask someone for help. You can send them a link or a diff showing exactly what changed. They don’t have to guess what you did.

When I’m building with Claude Code, I commit at the end of a feature, at the end of a session, or whenever the work’s at a natural stopping point I wouldn’t want to lose. If you’re starting out, commit at the end of each feature: it’s the cleaner rule, and most vibe-coding sessions cover one feature at a time anyway.

What to do:

• After any meaningful chunk of work (a new feature, a working fix, the end of a session): commit.
• Write the commit message in plain language. “Added dark mode toggle” is better than “changes.”
• If you’re using GitHub, push once or twice a day. That’s your off-site backup. Your .env file isn’t in it, because Git ignores it, so keep your keys in a password manager too.

Keep secrets out of your code and your Git history

A commit records everything in the folder, including keys you shouldn’t share. API keys, access tokens, database passwords and OAuth credentials are secrets, and anyone who has your key can use the service as you.

The rule: secrets never go into code, and they never go into Git history.

Both parts matter. A secret in a code file that gets committed to GitHub is leaked. A secret you paste into a prompt has already left your computer, and if the AI writes it into a file you commit, it’s in your history too. Keep keys out of prompts as well.

Why it matters more than you’d think:

• Deleting a secret doesn’t remove it from history. Delete it from a file, commit the deletion, push, and the secret is still in the history, where anyone with access to the repo can find it. Rewriting history to remove it is possible but painful, and by the time you’ve done it, assume someone already has the secret.
• Public repos are scanned automatically. Bots watch new commits to public GitHub repos for API keys, so a published key can be found and used quickly.
• Even private repos leak. Someone gets added to the repo, shares their screen, makes a backup. Each of these gives another person a way to see the key.

The fix: environment variables. A file called .env at the root of your project holds lines like:

OPENAI_API_KEY=sk-abc123...
BASECAMP_TOKEN=xyz789...
DATABASE_URL=postgres://...

Your code loads .env when it runs; the AI sets that up when it moves your secrets there. .env is listed in your .gitignore (see the next section), so it never gets committed. Every machine you work on gets its own .env file, filled in locally, never shared.

What to do:

• Never paste an API key into code, into a prompt or into a commit message. If you already have, rotate the key at the provider’s dashboard straight away, then put the new one in .env.
• Ask your AI: “Move every secret in this project into a .env file and update the code to read from it. Add .env to .gitignore.” It’ll do the refactor.

Add a .gitignore before your first commit

The file that keeps .env out of your history is the .gitignore. It tells Git “don’t track these”, so the files listed in it stay out of your commits. You want three kinds of thing in there: secrets, machine-generated files, and clutter from your editor and operating system.

Copy this into a file called .gitignore at the root of any new project:

# Secrets (always)
.env
.env.local
.env.*.local
*.pem
*.key

# Dependencies (keep the ones for the language you use)
node_modules/
venv/
__pycache__/
.pnp.*

# Build and generated output
dist/
build/
out/
output/
*.egg-info/

# Editor and OS clutter
.DS_Store
Thumbs.db
.vscode/
.idea/

# Logs
*.log
npm-debug.log*
yarn-debug.log*

Keep these in history:

• README.md, your notes to your future self on what this project is
• your rules file, such as CLAUDE.md or AGENTS.md (see the rules-file section below)
• package.json or pyproject.toml, the list of what your project depends on

These should all be committed. They’re how anyone, including you in six months, understands what the project is.

Try sorting a small project’s files into commit or ignore, and copy the template when you’re done.

# Secrets (always)
.env
.env.local
.env.*.local
*.pem
*.key
 
# Dependencies (keep the ones for the language you use)
node_modules/
venv/
__pycache__/
.pnp.*
 
# Build and generated output
dist/
build/
out/
output/
*.egg-info/
 
# Editor and OS clutter
.DS_Store
Thumbs.db
.vscode/
.idea/
 
# Logs
*.log
npm-debug.log*
yarn-debug.log*

What to do:

• Create .gitignore before your first commit. If you wait, it’s easy to commit node_modules/ or an .env file by mistake.
• To check whether a file is ignored: git check-ignore -v filename.
• Ask your AI: “Add a standard .gitignore for a [Python / Node / whatever] project, plus entries for .env and editor files.”

Keep each project in its own folder

The simplest organisational fix: one project lives in one folder, and nothing important lives on your Desktop.

It sounds obvious, and most vibe-coded projects I’ve seen break it. People have scripts in ~/Downloads, data files on the Desktop, and the main code in a folder they can’t find a week later.

Pick a top-level folder for all your code projects; ~/Dev/ works. Inside it, give each project a structure like this, adapted to what you’re building:

~/Dev/my-research-assistant/
├── README.md           # what this is, how to run it
├── .env                # secrets (in .gitignore)
├── .gitignore          # what NOT to track
├── CLAUDE.md           # rules for the AI
├── src/                # the code
├── data/               # input data files
├── output/             # generated output (in .gitignore)
└── scripts/            # one-off utilities

Not every project needs every folder. The point is that everything for one project sits together, and each folder’s name tells you what’s inside without opening it.

Every project folder has a README.md at the root, and it answers three questions:

1. What does this project do?
2. How do I run it?
3. What do I need to know before changing anything?

Even a three-sentence README is worth having. You are writing it for yourself six months from now.

What to do:

• Stop saving project files to your Desktop. Today.
• Make ~/Dev/ if you haven’t already. Move existing projects into it one at a time.
• Ask your AI: “Make a README for this project covering what it does, how to run it, and any gotchas.” It’s good at this because it already knows the code.

Write a rules file so the AI remembers

You shouldn’t have to re-explain the same things to your AI every time you open a session. A rules file at the root of your project tells the AI, every time, how to behave in this project: conventions, dependencies, what to prefer, what to avoid. Each assistant reads it automatically when it starts working in the folder.

Which file each assistant reads

Git works the same whichever assistant you use: the commands, the .gitignore and the .env file don’t change. Two things do change: whether the assistant can run commands in your project folder, and what its rules file is called.

Checked 26 October 2026, and the vendor pages re-read on 5 November 2026 (the Antigravity row comes from my own test). If you switch between tools on the same project, AGENTS.md is the one file they all read. Claude Code reads it when the project has no CLAUDE.md (version 2.1.277 or later); if you also want a CLAUDE.md, put @AGENTS.md at the top of it and Claude Code reads both.

Chat apps such as ChatGPT, Claude or Gemini in the browser can’t run commands on your computer. Use them to explain what a Git command does, then run it yourself or in a coding assistant.

What to put in a rules file

• What this project is. One paragraph. “This is a personal research assistant that reads RSS feeds and summarises them into a daily email.”
• The language, framework and stack. “Node 20, TypeScript, Cloudflare Workers.”
• Conventions you want respected. “Always ask before deleting files or running destructive commands.”
• Secrets rules. “Never paste API keys inline. Read them from .env, and never print a key in the chat.”
• Testing rules, if any. “Run npm test before suggesting a commit.”

Add a line each time you notice you’ve told the AI the same thing twice.

One rule has earned its keep in mine: don’t claim work is done until you’ve checked. A rule like “before telling me a fix worked, run the thing and show me the output” catches the most common AI-assisted failure, the confident “fixed!” that nobody checked. It’s one line in the file.

What to do:

• If your project has more than two sessions of history, it needs a rules file. Start simple: five bullets is fine.
• Ask your AI for the first draft: “Read the code in this folder and draft a rules file that covers what this project is, the conventions you’ve been using, and anything worth remembering across sessions.”
• Commit it. Every machine you copy the project to then gets the rules file too.

Leave branches and automation for later

Traditional Git tutorials front-load the hardest parts: branches, merges, rebases, pull requests, CI/CD. You don’t need any of it yet. Most of it exists for teams, and you’re working alone.

Two are worth knowing by name. You can do everything in one branch (main), and when you need to try two things at once without them interfering, that’s when to learn branches. CI/CD is automatic testing and deployment, which is worth it for real products with real users and not for your weekend experiment.

If the terminal puts you off, Git apps with buttons and menus (a GUI), such as GitHub Desktop, Tower and GitKraken, do the same job. If one of them gets you using version control at all, use it, because the goal is the habit. Tim Van Antwerp’s GitHub for Non-Programmers is a Creative Commons-licensed guide for people who don’t want to use the command line at all.

When you outgrow these habits, Simon Willison’s post on vibe engineering describes how experienced engineers use coding agents while staying accountable for the software they produce.

What to do:

• If something on this list comes up naturally (someone invites you to collaborate, or you need two parallel experiments), that’s when you learn it.
• Don’t feel bad about using a GUI.

Part 2 of 4 Practise

Try it on your own work

1. Make a project folder inside ~/Dev/ for something small you want to build.Result one folder with the project’s name, and nothing for it on your Desktop.

2. Create a .env file in it with a made-up key such as TEST_KEY=not-a-real-key.Result a .env file in the project folder containing that one line.

3. Ask your assistant to set up version control: “Put this folder under version control and add a standard .gitignore for [your language], plus .env and editor files. Show me git status before you commit anything.”Result git status lists .gitignore but not .env.
4. Ask for the first commit. Then run git log and git check-ignore -v .env.Result git log shows one commit, and the check prints the .gitignore line that matches .env.
5. Write a rules file with five bullets, using the file name your assistant reads from the table above, and ask the AI to commit it.Result git log shows a second commit that adds the rules file, and in a new session the assistant can tell you the project’s conventions when you ask.
6. Ask for a small change, then undo it: “Show me what changed since the last commit”, then “Undo everything since my last commit, including any new files.”Result the first shows the change; after the second, git status reports nothing to commit.
7. Make a change you want to keep and ask “Commit this with a plain-language message.”Result git log shows three commits, the newest with a message that says what changed.

Part 3 of 4 Check

Check yourself

Part 4 of 4 Keep

Read next

• Setting Up Your First CLAUDE.md File: a rules file in more depth, for Claude Code.
• Happy Birthday, Dear… how LLMs predict the next word: why an assistant can say “fixed!” with confidence and be wrong.