Never Losing Work

You are about to let AI change your code all day long. Without a safety net, one bad change can bury the version that worked, with no way back. Version control is that net, and this chapter hands it to you along with the words to make sure your AI uses it right.

2.4.1Git is your undo buttonAdd note

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.

2.4.2Your AI runs git, not youAdd note

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.

2.4.3Every experiment gets its own branchAdd note

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.

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.

2.4.4Commit after every working stepAdd note

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.

2.4.5Version numbers that tell the truthAdd note

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.

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 makes big refactors, deployments, and debugging far easier later.

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.

2.4.6Set the git rules onceAdd note

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

Act as a senior engineer managing version control for
my project. From now 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.
Explain what you are doing the first few times so I can
follow along.

My project:

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