Branches

Story

Building-a-house world — same site and crew as every Phase 0 lesson.

Before knocking out a wall in the real house, the crew builds a sample version off to the side — same starting plans as the real house, but on a separate patch of land. Try the risky idea over there. Tile a bathroom in a funky colour. Move the staircase. Whatever.

If it looks great, the crew copies that work into the real house (that's a merge). If it's a disaster, they tear the sample down and walk away — the real house was never touched.

And you can have several samples running at once: one crew testing a new kitchen layout, another testing solar panels, the robot worker trying a smart-lock wiring scheme. All from the same starting plans. All separate.

That separate-sample idea is a branch.

The idea

A branch is a parallel line of work in the repo. Same starting point as the rest of the project — separate place to make commits. Three things to know:

1. Every repo has a default branch. Usually called main (older repos: master). That's the "official" version — the real house.
2. You can make any number of side branches. Each has its own chain of commits. "Branches allow you to develop features, fix bugs, or safely experiment with new ideas in a contained area of your repository."
3. When you're done, merge it back — or delete it. Good result → copy into main (merge). Bad experiment → tear it down. Main stayed clean either way.

Why branch instead of committing straight to main?

• Experiments without risk. Try something. Break everything. Main stays untouched.
• Parallel work. Multiple people and agents work on different features at once without stepping on each other.
• Review before shipping. A branch sits at the approval desk (pull request, lesson 0.4) before it touches main.

The diagram — parallel, then rejoined

main had commits A → B. You create a branch off B and add commits C → D → E. Meanwhile the real house sits still. When you're done, the work merges back:

main:     A──B─────────────M
               \           /
branch:         C──D──E──/

A, B  = commits already on main (the real house's build diary)
C,D,E = your new commits on the sample build
M     = the merge point — sample work joins the real house

While C-D-E were happening, nobody touched the real house. The two lines ran in parallel, then came together at M. That's the whole idea.

(The merge point M — and what exactly happens at it — is what lesson 0.4 is about. For now: just see the shape.)

Real example — the syntax teaser

Not directly drilled on the GH-600 exam, but agents print these in logs and every study guide uses them. Recognize the shape.

The everyday flow — create a branch, work on it, merge back:

# See what branches exist (star = where you are now)
git branch                          # local branches
git branch -a                       # local + remote

# Create a branch AND switch to it (the most common move)
git checkout -b fix/empty-cart      # classic
git switch -c fix/empty-cart        # newer equivalent, same thing

# Make commits on the branch (git add + git commit from lesson 0.2)
git add .
git commit -m "fix: handle empty cart in checkout"

# Push the branch to GitHub so others / agents can see it
git push -u origin fix/empty-cart   # -u links local to remote for future pushes

# Done? Merge the branch back into main
git checkout main
git merge fix/empty-cart

# Housekeeping: delete the branch once merged
git branch -d fix/empty-cart                # local copy
git push origin --delete fix/empty-cart     # remote copy on GitHub

Branch naming — you'll see this pattern everywhere:

feat/copilot-instructions
fix/auth-token-expiry
chore/dep-bump-react-19
copilot/issue-42          # GitHub Copilot cloud agent's default pattern

GitHub Copilot's coding agent creates branches automatically using this type/description format when you assign it an issue. In audit logs, that pattern tells you at a glance: "this was the robot worker."

# Switch to an existing branch (no new branch)
git checkout fix/empty-cart
git switch fix/empty-cart           # newer equivalent

# Rename current branch
git branch -m new-name

# Force-delete (even if not merged — destroys unmerged work, be careful)
git branch -D fix/abandoned-experiment

# See commits on this branch not yet on main
git log main..HEAD --oneline

Why this matters for GH-600

When an AI agent works on your repo, it always works on a side branch, not directly on main. The agent's commits land on the branch, a pull request is opened (lesson 0.4), and only after a human — or a policy rule — approves does the work merge. The branch isolates the agent's changes until someone says "ship it."

This is the cert's core safety pattern: "Agents propose; humans and policy accept."

The branch is the propose half. Lesson 0.4 (pull requests) is the accept half.

Check-in — three quick questions

Open-ended. Think first, then peek at the suggested answer.

1. In one sentence — what is a branch?

   Suggested answer

   A branch is a parallel copy of the project's history where you can make commits without touching the main version, then merge those changes back in — or throw them away.

2. Your AI agent is about to make a risky change. Should it commit directly to main, or make a branch first? Why?

   Suggested answer

   Branch first. If the agent commits straight to main and breaks something, the official version is broken for everyone. On a branch the change stays isolated — it can be reviewed via a pull request before merging, and discarded if it went wrong.

3. What's the cert tagline that explains why agents work on branches instead of main?

   Suggested answer

   "Agents propose; humans and policy accept." The branch + PR is how the agent proposes. The human review or policy check is what accepts. Committing directly to main skips the accept step entirely.

Mentor marks this lesson verified after you compare answers and say "got it" in chat.