Testing AI Safely with Branches
Sarah needs two versions of her fundraiser flyer. One is formal for corporate sponsors. One is casual for social media. She doesn't want to lose either while working on both.
In the real world, you'd make two copies of the file. In Git, you create two branches: parallel versions of your entire project that can't interfere with each other.
"Branches let you live in two timelines at once, and only keep the one that works."
What Is a Branch?
You've used Track Changes to compare different versions of a document. Branches take that idea further. Instead of tracking changes to one file, a branch creates a parallel version of your entire project.
Your main branch is the "real" version: the one you trust. When you create a new branch, Git creates a new label pointing to the current snapshot. It feels like a copy because you can edit safely without touching main. If the changes work, you merge them back. If they don't, you throw away the branch name. The original is untouched.
Create Your First Branch
Open your terminal in your fundraiser project (from Lesson 1). Let's create a branch for Sarah's formal flyer.
What you tell your agent: "I want to work on a formal version of the flyer without changing the main project."
What the agent does:
git branch formal-flyer
That created the branch. But you're still on main. Check:
git branch
formal-flyer
* main
The asterisk shows you're on main. Now switch:
git switch formal-flyer
Switched to branch 'formal-flyer'
You're now on the formal-flyer branch. Everything looks the same because the branch starts as an exact copy of main.
Changes Stay on Their Branch
Now make a change that only exists on this branch.
What you tell your agent: "Create a formal flyer for the fundraiser."
What the agent does:
echo "FORMAL FLYER: Annual Community Fundraiser Gala" > flyer.txt
echo "Date: March 15 | Venue: Grand Ballroom | Dress Code: Business Formal" >> flyer.txt
git add flyer.txt
git commit -m "Add formal flyer for corporate sponsors"
The flyer exists on formal-flyer. Now switch back to main:
git switch main
ls
The flyer is gone. It only exists on the formal-flyer branch. Your main project is completely untouched. This is branch isolation in action.
If Sarah decides the formal flyer is terrible, she can delete the branch. Main stays exactly as it was. No risk.
Test Two Ideas at Once
Sarah also wants a casual flyer. Create a second branch from main:
git branch casual-flyer
git switch casual-flyer
Make the casual version:
echo "HEY NEIGHBORS! Community Fundraiser Party!" > flyer.txt
echo "Food, music, fun. Bring the whole family. Donations welcome!" >> flyer.txt
git add flyer.txt
git commit -m "Add casual flyer for social media"
Now Sarah has three versions of her project:
main: the original, no flyer yetformal-flyer: formal version for sponsorscasual-flyer: casual version for social media
Each exists independently. She can switch between them to compare.
Merge the Winner
Sarah decides the casual flyer fits her audience better. Time to bring those changes into main.
Step 1: Switch to main first.
git switch main
Step 2: Merge the winning branch.
git merge casual-flyer
Updating abc1234..def5678
Fast-forward
flyer.txt | 2 ++
1 file changed, 2 insertions(+)
"Fast-forward" means main hadn't changed since you branched off: Git simply moved main forward to include the new commits. No merging was needed because there was nothing to merge with.
The casual flyer now exists on main. Verify:
cat flyer.txt
Step 3: Clean up.
git branch -d casual-flyer
git branch -d formal-flyer
The branch names are deleted. The commits from casual-flyer are preserved in main's history. The formal-flyer commits were never merged, so they are no longer part of Sarah's main workflow.
git branch -d only deletes the branch name, not the work. After merging, the commits live on in main. If you try to delete a branch you haven't merged, Git warns you. Use -D (capital D) only if you're sure you want to throw away unmerged work.
Branch Naming
Good branch names tell you what's happening at a glance:
feature/formal-flyer: adding something newexperiment/new-layout: testing a risky ideabugfix/broken-budget: fixing a problem
Bad names like branch1 or test tell you nothing in a week. Name branches by what they do, not when you made them.
When to Branch vs When to Commit
Not every change needs a branch.
Use a branch when:
- You're testing two or more approaches
- The change might break something
- You want to review before merging
- Someone else might be working on the same project
Commit directly to main when:
- You're confident the change is small and correct
- You're the only person working on the project
- The change is a quick fix, not an experiment
A simple test: If you're thinking "this might go wrong," create a branch.
You can test ideas in two timelines. But both timelines only exist on YOUR computer. What if your hard drive crashes tomorrow?
That's what the next lesson solves.
Try With AI
Understand branch isolation:
"Explain why files I create on a Git branch disappear when I switch to main. Use a real-world analogy that isn't about parallel universes or video games. Help me understand why this is useful, not scary."
Practice comparison workflows:
"I want to test two different approaches to a project: one simple and one advanced. Walk me through the branch workflow: create both branches, work on each one, compare results, merge the winner, and clean up. Include the exact commands my agent would run."
Explore naming conventions:
"What are good Git branch naming conventions? Show me examples for features, experiments, and bug fixes. Then help me decide: should I name branches by what they do (feature/new-flyer) or by when I made them (experiment-march-15)?"
Know when NOT to branch:
"I'm tempted to create a branch for every tiny change. Give me five realistic scenarios and for each one, tell me whether I should branch or commit directly to main, and explain why. Help me build instinct for when branching is overkill."