Git for Vibe Coders: The Minimum That Saves a Project

Git is a system that remembers the history of changes in a project. Every time you tell it to save, it takes a snapshot of all your files, and you can return to any snapshot later.

If you build apps with AI, git is not a tool for “real programmers”. It is insurance. An assistant can rewrite twenty files in a minute, and sometimes nothing works afterwards. Without git, you try to remember how things were. With git, you go back to the previous version with one command. Here is the minimum git for vibe coders that keeps you from losing work.

A commit is a save point

A commit is a snapshot of the project with a short label describing what changed. Think of saving a game before the boss fight.

The main rule of vibe coding with git: commit every working state. The assistant added a form, you checked that it works: commit. Then ask for the next change. If that one breaks everything, you roll back to the form that worked, not to the state from three days ago.

Write labels for yourself a month from now. “Stripe checkout, no webhooks yet” is more useful than “fix” or “changes”.

A branch is a draft

A branch lets you try something risky without touching the working version. The main branch is usually called main. Want the AI to redo all your navigation? Create a branch and experiment there. If it works, merge it into main. If it does not, switch back to main as if nothing happened.

One or two branches for experiments is plenty at the start. Elaborate branching strategies are for teams, not for one person and an assistant.

The minimum set of commands

Many editors, as well as Lovable, Bolt and Replit, handle git through buttons, but it helps to know what sits behind them:

git status                        # what changed since the last commit
git add .                         # stage all changes for the commit
git commit -m "Email login works"
git log --oneline                 # commit history
git switch -c try-new-nav         # create a branch and switch to it
git switch main                   # go back to the main branch
git restore .                     # throw away uncommitted edits
git revert <commit id>            # undo a specific commit with a new commit
git push                          # send commits to GitHub

The two undo commands are different. git restore . throws away what you have not committed yet, such as a bad edit from the assistant. git revert undoes a commit you already made, but instead of erasing history it adds a new “opposite” commit. That is safe. Avoid commands with reset --hard and push --force until you understand exactly what they will delete.

GitHub is a copy that will not die with your laptop

Git keeps history on your computer. GitHub (or GitLab, or Bitbucket) keeps a copy online. It is a backup, a way to show your code to a developer, and the basis for automatic deployment.

Make the repository private unless you mean to open-source the code. And run git push at least at the end of every working day.

Never commit secrets

This is the most important rule here. API keys, database passwords and tokens live in a .env file, and that file must be listed in .gitignore, the list of things git does not track. Check it right now: open .gitignore and look for .env.

If a key has already been committed, deleting the file in the next commit is not enough. The key stays in the history, and anyone with access to the repository can find it. In public repositories, automated scanners find keys on their own. The right order: revoke the key in the service’s dashboard, issue a new one, put it only in .env. Cleaning the history comes later, if at all.

Where to start today

1. If the project is not in git yet, initialise a repository (git init) or turn on GitHub sync in your tool.
2. Check .gitignore: it should include .env, node_modules and build folders.
3. Make a first commit of the current working state.
4. Create a private repository on GitHub and push your code there.
5. From now on, commit after every change that works.

In short

• Git stores your project’s history and lets you return to any saved version.
• Commit every working state: it is your rollback point when the AI breaks something.
• Branches are for risky experiments; main is for what works.
• GitHub is a copy of your project off your computer; keep the repository private.
• Secrets live in .env under .gitignore; a key that leaked into history must be replaced, not just deleted.

SUBXCAT can help tidy up a repository and its history before you hand it to a team or launch.