Git is presented as a collaboration system and taught as one, which is why it feels like overkill for one person and a folder. Reframe it: git is an undo button that survives closing the editor, and a way to try something risky knowing you can get back.

For vibe coding specifically it is close to essential, because the failure mode of working with a model is that something works, then a helpful rewrite happens, and the working version is gone.

The six commands

git-basics.txt
git init                      # once, in your project folder
git add -A                    # stage everything you changed
git commit -m "message"       # save a snapshot
git log --oneline             # list your snapshots
git diff                      # what have I changed since the last one?
git restore .                 # throw away everything uncommitted

That is a working setup. Branches, remotes, rebasing and the rest are real and useful, and none of them are needed to get the benefit.

The rhythm that matters

Commit whenever something works, before you ask for the next change. Not at the end of the session. The moment the thing does what you wanted, snapshot it — that is the version you will want back in twenty minutes.

This turns a bad model interaction from a disaster into an inconvenience. Rewrote your whole file? git restore . and you are back to working, having lost only the last few minutes.

Say what changed, not what happened

"Update" and "fix" tell you nothing in a list of forty. One line about what changed and why is enough:

commit-help.txt
Here's my diff: <paste>

Write a commit subject line under 72 characters, imperative, saying
what changed and not which files. If this diff is really two unrelated
changes, tell me where to split it.

Before you push anywhere public

Check what you are about to publish. git status before your first commit, every time, and make sure .env, key files and anything with a password in it are in .gitignore before they get committed — a secret that has been committed is in the history even after you delete the file.

If you have already pushed a key, deleting it from the file is not enough. Rotate the key. Assume it was read.

Working with a model on a repo

Tell it the state of your working tree. "I have uncommitted changes to two files" changes the advice you get. And when a model suggests a git command that rewrites history — reset --hard, push --force, anything with filter in it — read it twice and commit first. Those are the ones that lose work.