Version Control: Never Losing Work | Vibe Coding with Confidence

Your app skeleton runs, and right now there is no way back to it. You are about to let AI change your code all day long, and without a safety net one bad change buries the version that worked. Version control is that net, and this chapter hands it to you along with the words to make sure your AI uses it right.

1.10.1Git is your undo button

Git is a tool that saves a snapshot of your whole project every time something works. Each snapshot is a commit, and you can jump back to any of them, so a version that ran is never more than one step away. The folder git watches is your repo, short for repository.

Unlike the undo in a text editor, git never forgets and never runs out. Months of commits stay there, each one a safe place to return to.

1.10.2Your AI runs git, not you

Here is the relief: you will not memorize a single git command. Your agent runs every one of them for you.

What you need is not the typing, it is the judgment: knowing what should be happening, so you can tell when it is being done right. That is all this chapter is for.

1.10.3Save your running skeleton first

Your first commit is the skeleton you just got booting. Nothing you have added can have broken it yet, which makes it the one state you always want a way back to.

git init git add -A git commit -m "chore: scaffold running skeleton"

From here every change is measured against a version you know ran. When something breaks, and it will, getting back to working is one step, not an afternoon.

1.10.4Every experiment gets its own branch

When AI tries a new feature, it should do it on a branch: a private copy of the project split off from the main line. If the feature works, the branch is merged back in. If it breaks, you throw the branch away and the working version, the main branch, never felt it.

Each experiment runs on its own branch, merged back only if it works.

You may also hear about worktrees, a way to keep several branches open at once. Same idea, and your agent handles it. You do not need to.

1.10.5Commit after every working step

One habit matters more than the rest: have your agent commit after each small change that works, never one giant commit at the end.

Small commits are precise. When something breaks, you undo the one step that caused it instead of losing an afternoon of work.

Rule of thumb: if it runs and does one new thing, commit it.

1.10.6Let git run your checks for you

Git can also run a check for you automatically, the moment you commit. That automatic check is a hook: a small script git triggers on its own, so the things you would otherwise forget just happen every time.

As the project grows you will put a few jobs here: a formatter to tidy the code's layout, a linter to flag sloppy patterns, and a scan for leaked keys. Your tests go here too, the small programs that check your app still does what it should.

You own none of those yet, so there is nothing for a hook to run today, and that is fine. Each one joins it as it arrives: the formatter and linter when you settle your code conventions, then the secret scan and the tests in the parts that set them up. What you need now is knowing the slot exists, so quality never depends on you remembering.

A git hook runs your quality checks automatically the moment you commit.

1.10.7Version numbers that tell the truth

When you share software, its version number tells people what changed. The standard is semantic versioning: three numbers like 2.4.1, each with a job.

Number	Goes up when	Example
Major	a change breaks how it worked before	1.9 to 2.0.0
Minor	you add a feature, nothing breaks	2.3 to 2.4.0
Patch	you fix a bug	2.4.0 to 2.4.1

Start numbering from your very first working version, not once things get serious. With versions in place you always know where you stand: which one is live, what changed since, and, when a bug appears, which version introduced it.

That one early habit pays off later at every deployment. That is the moment you send a version out of your machine and onto real servers where users reach it.

You do not work the numbers out yourself. Tell your agent to follow semantic versioning from the first release, starting around 0.1.0, and your history stays honest about what changed.

1.10.8Set the git rules once

Give your agent these rules at the start, and it handles version control for the whole project:

Ready prompt

Act as a senior engineer setting up version control. First read my rules file, so your commit style and branch names match what is already written there. Then start git here and commit the app skeleton exactly as it boots, as my baseline. From then on, without me asking each time: - Commit after every change that works, with a short, clear message saying what changed. - Put each new feature on its own branch, and merge it back only once it works. - Follow semantic versioning for releases: major for a breaking change, minor for a feature, patch for a fix. Add those three as standing rules in my rules file, so every session follows them. Explain what you are doing the first few times so I can follow along. If you need the full reasoning behind this step, read https://zalt.me/guides/vibe-coding/setup/version-control My project:

Do this now: paste the prompt above to your agent, so your running skeleton is saved and version control is live before you write another line.

1.10.1Git is your undo buttonAdd note

1.10.2Your AI runs git, not youAdd note

1.10.3Save your running skeleton firstAdd note

1.10.4Every experiment gets its own branchAdd note

1.10.5Commit after every working stepAdd note

1.10.6Let git run your checks for youAdd note

1.10.7Version numbers that tell the truthAdd note

1.10.8Set the git rules onceAdd note