Git for AI 2, branches and reviews

What this is about

Lesson 1 gave you the safety net. This lesson takes you to the level where you actually feel relaxed working with the AI. Three things: branches as a sandbox, reading diffs before you commit, and why you should never blindly leave rollbacks to the AI.

Why branches exist

Imagine you have a working project. Login works, payment works, all good. Now you want Claude to build a new feature, say dark mode.

Dark mode is a small change you think. What could go wrong.

In practice: Claude touches the theme system, also touches the CSS layout, adds a new library, and suddenly the login screen looks broken. If you did all of this directly on your main state, you now have two problems instead of one.

Branches solve this. A branch is a parallel version of your project where you can try things without touching the main state.

In the save-game metaphor: a branch is when you copy your save before going into the hard dungeon. If you die and do not like the copy, you delete it. The original is untouched.

Branch-per-ask, the most important pattern

The rule is simple. Before each bigger AI task, you create a new branch.

In GitHub Desktop top middle there is a branch dropdown. Click it, "New branch". Name it, for example feature/dark-mode. Click.

You are now on a new branch. Anything you or the AI does here does not touch your main state.

Now you let the AI build.

Three possible outcomes:

1. Works and looks good. Commit, switch back to main, merge the branch in. Done.
2. Half works, you want to keep going. Commit on the branch, keep working, merge later when it all fits.
3. Garbage. Switch to main, delete the branch, go to lunch.

Outcome 3 is why branches exist. Without one, you would now be cleaning up. With one, you lost nothing.

Reading the diff, the underrated move

A diff is the list of all changes since the last save state. Which lines were added, which removed, in which file.

In GitHub Desktop you see this automatically. Click a changed file on the left, on the right you see line by line what changed. Green is new, red is gone.

Before you commit anything, look at the diff. One minute is enough.

You are looking for three things:

• Did the AI change things you did not ask for? Classic Claude and Cursor pattern: you ask for one function, the AI refactors three other ones because it thinks they are nicer that way. Diff shows you that.
• Are files gone that you need? AI sometimes deletes code it considers unused but is called from somewhere else.
• Are there secrets in there? API keys, passwords, .env contents. If you commit and push that to GitHub, it is on the internet forever, even if you delete it later. Diffs catch this.

If the diff looks clean, commit. If not, send the AI back at it or discard the changes.

Pull requests, even when working alone

Pull request sounds like team work. You can use it solo though, and it is worth it.

Workflow:

1. You are on a branch (e.g. feature/dark-mode), changes are in.
2. Push the branch to GitHub (click in GitHub Desktop).
3. On github.com you see a banner "compare and pull request". Click.
4. You land on a page that shows you the entire diff big and readable.
5. You can comment, approve, merge.

What you get out of it: you see the changes again in a completely different view. Sometimes you spot something in the browser view that you missed in the editor. Plus you have a nice history on GitHub with descriptions of why you did what.

The trap, Claude and git reset --hard

Now to a warning that is in almost no beginner tutorial.

If you tell Claude Code "can you undo that", it can happen that Claude runs git reset --hard. That is a destructive command. It deletes everything since the last commit with no recovery. If you had two hours of uncommitted changes, they are gone.

There is an official bug report in the claude-code repo (Issue 17190 from January 2026) where exactly that happened and the reporter lost hours of work.

What to do instead:

• If you want to go back to an earlier commit, do it yourself in GitHub Desktop. Right-click the commit, "Revert this commit". That is the safe path, all changes stay in history, the revert itself is a new commit.
• If you are inside Claude Code and want to undo only the last changes, use the built-in /rewind command (also aliased as /checkpoint). That is Claude's own safe undo, it rolls back code AND conversation to the chosen point.
• If you want to give Claude a specific cleanup task, be concrete. "Delete the last changes in src/auth.ts and restore the state from commit a3b4c5" is much safer than "undo it".

Rule of thumb: rollbacks happen in the GUI or with /rewind. Never as a vague command to the AI.

Commit discipline

One last thing. Make more commits, shorter ones.

Beginners often build for an hour and then make one giant commit "everything done". If something breaks afterwards, the commit is so big that the rollback wipes the whole hour.

Better: commit every 15 to 30 minutes, or whenever a small step is done. A nice beginner rule is: commit briefly before EVERY task you give the AI. That way you always have a save state right before the next change.

What you can do now

• Create branches and apply the branch-per-ask pattern
• Read diffs and recognize three typical AI problems in them
• Use pull requests for solo work
• Distinguish safe from destructive rollback commands
• Find a sensible commit frequency

Lesson 3 shows you the pro move: the GitHub MCP Server. With it Claude Code can talk directly to your GitHub account, read issues, open pull requests, debug CI failures.