Git basics for vibe coders: the commands that save you (2026)
The dozen Git commands and habits a person building with AI agents actually needs: saving working states, seeing what the agent changed, undoing safely, branches for experiments and keeping secrets out of history.
Key Takeaways
- Git is an undo history for your whole project. Each commit is a snapshot of every file. If the agent breaks something, you can see the difference and go back.
- Commit every time something works. A green state you can return to is the most valuable thing in a vibe coding session. Small, frequent commits make every mistake cheap.
- Use branches for experiments. Try a risky change on a branch. If it works, merge it; if not, switch back and delete it. Your main version never had the mess.
- Keep secrets out from the first commit. Add .env to .gitignore before you commit anything. A key that reaches history, especially on a public repo, should be treated as leaked and rotated.
- Git protects code, not data. Reverting a commit doesn’t bring back database rows a migration deleted. That needs a database backup.
Quick-Start Prioritization Framework
| You want to… | Command | Notes |
|---|---|---|
| Start tracking a project | git init | Once per project |
| See what changed | git status, then git diff | git diff --stat for a summary |
| Save a working state | git add -A then git commit -m 'message' | Do this every time a check passes |
| See history | git log --oneline | One line per commit |
| Throw away uncommitted changes to one file | git restore path/to/file | Can’t be undone |
| Undo a commit safely | git revert <commit> | Adds a new commit that reverses it |
| Try something risky | git switch -c experiment | Creates and moves to a new branch |
| Back up to GitHub | git push | After adding a remote |
Coding agents make changes fast, across many files at once. That’s the point, and it’s also why you need a way to see exactly what changed and get back to the last version that worked. Git is that way. You don’t need to master it. You need about a dozen commands, three habits and an understanding of what Git can’t undo. This guide covers those, with the exact commands, the prompts to hand the routine work to your agent, and the mistakes that cost vibe coders the most, especially secrets in history and data loss that version control never protected in the first place.
Why vibe coders need Git more than anyone
When you write code by hand, you change a few lines at a time and remember what you did. An agent can change 30 files in a minute, and a follow-up prompt can quietly undo a feature that worked an hour ago. Without history, your only recovery tool is asking the agent to put things back, from its memory of a conversation that may already have been compacted.
Git records snapshots. The Pro Git book, the project’s official guide, describes Git as thinking of its data “like a series of snapshots of a miniature filesystem.” Every commit is one of those snapshots, and you can compare or return to any of them.
Three ideas that make Git make sense
You can use Git for years without knowing its internals, but these three ideas prevent most confusion.
Files have three states
Pro Git puts it simply: files can be modified, staged or committed. Modified means changed but not saved to history. Staged means marked to go into the next commit (git add does this). Committed means stored in history. Most “where did my change go?” moments are a file stuck in one of the first two states.
A commit is a save point with a label
Each commit has an ID (a long hash, usually shown as its first seven characters) and your message. Messages matter more than you’d think: “Add class booking with capacity check” is findable in a month; “fixes” isn’t.
A branch is a separate line of work
The main branch (usually called main) is your real app. A branch is a copy you can change freely. Branches are cheap, and switching between them changes the files on disk to match.
Setting up a project
Do this once, before the first prompt.
Initialise and ignore the right files
In your project folder run git init. Then create a file called .gitignore listing what must never be committed. GitHub’s docs describe .gitignore as the way “to tell Git which files and directories to ignore when you make a commit.” A sensible start for a JavaScript project:
- .env and .env.local (secrets)
- node_modules/ (installed packages; recreated from package.json)
- dist/ and build/ (generated output)
- .DS_Store and other editor clutter
Make the first commit
git add -A stages everything not ignored. git status shows what will be committed: read the list and make sure no .env file is there. Then git commit -m 'Initial project'.
Or let the agent do it
Claude Code’s docs note that it works directly with Git: it stages changes, writes commit messages, creates branches and opens pull requests. A reasonable prompt: “Initialise a Git repository with a .gitignore for this stack that excludes .env files and node_modules. Show me git status before committing.”
The working loop: prompt, check, commit
This loop is the whole habit.
1. Start from a clean state
Run git status before prompting. If it shows uncommitted changes, commit or discard them first, so the next diff only contains what the agent does now.
2. Prompt and let the agent work
Ask for one feature or fix at a time, with a check the agent can run.
3. Look at what changed
git diff --stat lists the files and line counts. git diff shows the actual changes. Even if you can’t read the code, you can see whether the agent touched files you didn’t expect.
4. Commit if it works
Test it, then git add -A and git commit -m 'Describe what now works'. Or tell the agent: “Commit these changes with a descriptive message.” Each commit is a point you can return to.
Undoing things safely
Most Git anxiety is about undo. Here are the cases in order of how often they happen.
The agent made a mess and you haven’t committed
git restore path/to/file throws away uncommitted changes to that file. git restore . does it for every tracked file. Both are permanent for those uncommitted changes, so check git diff first. New files the agent created aren’t touched by restore; git status lists them as untracked and you can delete them.
A commit broke something
git log --oneline finds the commit. git revert <commit-id> creates a new commit that reverses it. History stays intact, which makes this the safe choice, especially if you’ve already pushed.
You want to look at an old version without losing the current one
git switch -c look-back <commit-id> creates a branch at that old commit. Look around, then git switch main to come back.
Commands to be careful with
git reset --hard, git clean -fd and git push --force can permanently delete work. Agents sometimes reach for them to “clean up.” It’s reasonable to tell your agent, in CLAUDE.md or AGENTS.md: “Never run git reset --hard, git clean or force-push without asking me first.”
Branches for experiments
Branches let you try a risky idea without betting the working app on it.
The routine
git switch -c try-new-checkout creates a branch and moves to it. Prompt away. If it works: git switch main then git merge try-new-checkout. If it doesn’t: git switch main then git branch -D try-new-checkout, and it’s gone.
Running agents in parallel
Advanced users run several agents at once, each on its own branch in its own folder, using git worktree. It avoids agents overwriting each other’s files. If you’re starting out, one agent on one branch at a time is plenty.
GitHub: backup and collaboration
Git lives on your computer. GitHub (or GitLab, or Bitbucket) keeps a copy online.
Push regularly
Create an empty private repository on GitHub, follow its instructions to add the remote, then git push. After that, git push after each session is your off-machine backup.
Private by default
Make the repository private unless you mean to publish the code. Public repositories are scanned constantly by people looking for leaked keys. GitHub runs secret scanning automatically for free on public repositories, which helps, but rotating a leaked key is still on you.
Pull requests, even solo
A pull request is a page showing a branch’s changes before merging. Working solo, it’s still a convenient place to review a diff and run an AI review. Claude Code’s /code-review command accepts a pull request number as its target.
Common mistakes
The Git mistakes that cost vibe coders the most, roughly in order of pain.
Committing a secret
If a key reached a commit, deleting the file in the next commit doesn’t remove it from history. Treat it as leaked: revoke it at the provider and issue a new one. If the file is still tracked, GitHub’s docs say you must untrack it with git rm --cached FILENAME before a .gitignore rule takes effect.
Going hours without a commit
The longer since the last commit, the more a bad prompt can cost. Commit whenever something works, even if it’s small.
Believing Git backs up the database
Git tracks files. Your users’ data lives in a database on a server. A migration that drops a table is fixed only by a database backup or point-in-time restore.
Letting the agent force-push or hard-reset
Those commands rewrite or erase history. Keep them behind your explicit approval.
Messages like “update”
You’ll search history when something breaks. Describe what works now, not what you did.
If you’d rather not do this yourself
If you’d rather not manage Git and a separate database backup routine, some platforms handle versions and data restores for you. Floot, for instance, lets you download your app’s database on every plan and restore it to any moment in the last 7 days on paid plans.
Frequently Asked Questions
Do I need Git if I use an app builder like Replit or Lovable?
Builders keep their own checkpoints or versions, which cover the same need inside the builder. Git becomes important when you work with a coding agent on your own computer, or want a copy of the code outside the builder.
What’s the difference between Git and GitHub?
Git is the version control tool that runs on your computer. GitHub is a website that hosts Git repositories online for backup, sharing and pull requests.
How often should I commit when vibe coding?
Every time something works and a check passes. Several times an hour is normal during active building.
Can the AI agent handle Git for me?
Yes. Claude Code, Codex and Cursor can stage, commit, branch and open pull requests. Still read git status before commits and keep destructive commands behind your approval.
I committed my .env file. What now?
Rotate every key in it at each provider, untrack the file with git rm --cached, add it to .gitignore and commit. Deleting the file later doesn’t remove it from history.
What’s the safest way to undo a bad commit?
git revert with the commit’s ID. It adds a new commit that reverses the change and keeps history intact.
Sources
- Git, Pro Git: What is Git?, 2026 https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F
- GitHub Docs, Ignoring files, 2026 https://docs.github.com/en/get-started/git-basics/ignoring-files
- GitHub Docs, Secret scanning, 2026 https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
- Anthropic, Claude Code overview, 2026 https://code.claude.com/docs/en/overview
- Anthropic, Review locally with /code-review, 2026 https://code.claude.com/docs/en/code-review-local