Class 5 introduced the idea of a branch. Now use it as an operating habit: keep the working version stable, give a focused change its own branch, let the AI work inside that boundary, review the diff, and merge only when the evidence is good.

The branch workflow

main
  ↓ create a focused branch
feature/add-company-comparison
  ↓ agent reads context and builds
  ↓ local tests and browser review
  ↓ commit the approved change
  ↓ push branch to GitHub
  ↓ pull request / review
  ↓ merge into main

The branch name should explain the job. feature/add-company-comparison is better than new-stuff. You should be able to look at a branch and know what it was meant to change.

Give the agent a branch boundary

This protects the main project from scope creep. It also makes review easier because the changed files should tell one coherent story.

Parallel does not mean shared edits

For advanced parallel work, Git worktrees let you have separate local folders for separate branches at the same time. You do not need them at the beginning. The underlying principle is enough: each active builder needs an isolated place to make changes.

Review before merge

A green test result is necessary but not sufficient. Review the diff and answer:

1. Did the agent touch only expected files? 2. Did it add a dependency or configuration change you did not request? 3. Did you test the real behavior in the browser? 4. Is the branch still aligned with the original brief? 5. Does the handoff explain what remains?

Merge is the moment when an experiment becomes part of the shared product history. Treat it as an approval decision.

A branch needs a clean ending

Every branch should end in one of three states: merged because it is approved, closed because the idea was rejected, or retained with a clear note about what blocks it. Do not leave a growing cemetery of mystery branches. Their names, pull requests, and handoffs should tell you what happened.

This is particularly important with AI experiments. “Agent tried a new onboarding flow; rejected because mobile navigation became confusing” is valuable institutional memory. It stops a future agent from repeating the same work and helps you distinguish a failed implementation from a rejected product decision.

Practical exercise

For a small documentation change, create a branch with a clear name. Ask an agent to edit only one Markdown file. Review the diff, commit it, and write a one-paragraph pull-request description explaining what changed and how you checked it.

Check your understanding

1. Why does a focused branch make AI work safer? 2. When do two agents require separate branches? 3. What is a pull request for? 4. What should you inspect before merging?