Committing on purpose

You know the four git commands. This is about using them deliberately once an assistant is writing most of the code.

Commit before you ask, not just after

A clean starting point is what makes a generated change reversible. If you have uncommitted work of your own mixed with a generated diff, undoing one means untangling both.

So: commit what works, then ask for the next thing. It costs ten seconds and it is what turns "this broke everything" into git checkout ..

One change, one commit, one sentence

git commit -m "check res.ok before parsing, so a 429 stops showing blank rows"

What changed, and why. The why is the part you cannot reconstruct later, and it is the part an assistant cannot write for you — it does not know why you wanted it.

What must never be committed

Secrets. An API key committed once is in the history forever, and deleting it in the next commit does not remove it — anyone who cloned the repository still has it.

This is why .gitignore exists and why course 1 spends a whole lesson on the key. The rule to carry from here: before every commit, look at what you are about to add. git status and git diff take five seconds.

Undoing, three ways

git checkout .                 throw away uncommitted changes
git reset --soft HEAD~1        undo the last commit, keep the work
git revert <commit>            add a commit that undoes an old one

The first is the one you will use constantly, and knowing it exists changes how you work: an experiment you can throw away in one command is an experiment worth running.

Try it now

Make a change you do not want, then throw it away with git checkout .. Then make one you do want and commit it with a real sentence. Feeling how cheap the undo is changes how willing you are to try things, which is most of what makes people improve quickly.