Parallel Universes: Branching for AI Experiments
"A branch is a safe space to be wrong. Create one every time you have an idea."
Branches are what make Git magical. They let you experiment freely — try a wild AI refactor, explore an alternative architecture — without ever risking the stable codebase. Think of them as parallel timelines that you can merge back or discard entirely.
main branch. The main branch represents the official, stable, production-ready code. Your work must happen in an isolated
"parallel universe" called a branch.3.1 "I Have a New Idea (or AI Prompt)"
You have a feature idea — or maybe an ambitious AI prompt that might refactor half your codebase. Before you do anything, create a branch where it's safe to experiment.
First, make sure you're on main and it's up to date. Then create your branch:
git switch -c feature/my-new-idea
# Older equivalent: git checkout -b feature/my-new-ideaIn VS Code, this is even easier. Look at the bottom-left corner of your window -- you'll see the current branch name (e.g., "main"). Click it and you'll get a dropdown where you can switch to existing branches or select "+ Create new branch..." to make a new one:
When you click the branch name, VS Code opens a Quick Pick menu listing all your branches.
Select "+ Create new branch..." at the top, type a name like feature/my-new-idea, and you're immediately switched to it:
main is — but it isn't a copy of anything. A branch is just a label pointing at a commit
(which is why creating one is instant, and why you can have hundreds). From here on, new
commits move your label while main's stays put. If the AI destroys everything, it
does not matter: discard the branch and switch back. This workflow enables fearless experimentation.git reset --hard HEAD~1 to remove the commit from main. (Reading that address: HEAD is the commit you're standing on, and ~1 means "one step back" — so HEAD~1 is the previous commit, HEAD~3 three commits back.) You'll master git reset in Part 4. One precondition: make sure git status is clean first — --hard also wipes any uncommitted edits, and those have no undo. Try it yourself
below:Try It: Oops — Committed to Main
main that should be on a feature
branch. Create the branch, then reset main with git reset --hard HEAD~1.Loading playground...
"Create a new branch called feature/user-auth and switch to it"
"I need to start working on the payment integration — set up a branch for me"
3.2 "My Teammate Pushed Updates" (Syncing)
You're not working in a vacuum. While you've been building your feature, your teammates have been merging theirs. Staying in sync is how you avoid painful surprises later.
main. Your branch is now "stale."Before diving into the commands, here's how the three main remote operations relate to each other:
Fetch downloads without merging. Pull = fetch + merge. Push uploads your commits.
Option 1: The "Safe" Sync (fetch + merge)
git fetch origin # Download new commits (doesn't apply them)
git merge origin/main # Merge the updates into your branchOption 2: The "Easy" Sync (pull)
git pull origin main # Fetch + merge in one commandgit fetch first to see what's coming before merging. git pull is just a "black box" shortcut.git pull refuses to run: if your branch and the remote have both moved (you committed locally, a teammate
pushed), modern Git stops with fatal: Need to specify how to reconcile divergent branches. It's asking which strategy you want: git pull --no-rebase (merge, like this section) or git pull --rebase (replay your commits on top — the cleaner habit you'll learn in section 5.2). Pick a default once
with git config --global pull.rebase true and you'll never see the error again.VS Code makes syncing visual. Look at the status bar at the bottom of your window -- you'll see small arrows with numbers showing how many commits are incoming (to pull) and outgoing (to push). Click the sync icon (circular arrows) to pull and push in one step:
You'll also see a prominent "Sync Changes" button right in the Source Control panel. It shows the exact count of incoming and outgoing commits, so you always know what's about to happen:
Try It: Fetch and Merge Remote Updates
origin — no real network calls. After git fetch origin, run git log --oneline --all to see both local and remote branches.Loading playground...
"Pull the latest changes from main and update my branch"
"Fetch from origin and tell me if my branch is behind main"
3.3 "My AI-Generated Feature is Ready" (The Pull Request)
Your feature is built, tested, and committed. But you don't just push it into production — you propose it. A pull request is a conversation: "Here's what I built. Let's review it together."
main. You do not merge it directly. You "propose" the change via a Pull Request (PR).Once your feature is ready, push your branch to the remote so your teammates can see it:
git push -u origin feature/my-new-idea
# -u links your local branch to the remote branchThen on GitHub, you'll see a yellow banner: "feature/my-new-idea had recent pushes. Compare & pull request." Click it to create your PR.
main. (One vocabulary note for job interviews: "pull request" is the
GitHub/Bitbucket name. GitLab calls the identical thing a merge request (MR) — and it's a forge feature, not a Git command. Part 9 tours
the forges beyond GitHub.)The Modern PR Arc: Draft → Ready → Review → Merge
Open work-in-progress as a draft PR — visible to the team, CI running, but explicitly not asking for review yet. Click "Ready for review" when it is. Drafts stopped being a nicety in the agent era: every cloud coding agent (GitHub Copilot's coding agent, Claude, Codex, Devin) delivers its work as a draft PR for you to review — so this arc is the one you'll live in daily.
Two more things you'll meet on your first real PR:
- The merge button is a menu. "Merge commit" preserves your branch's commits; "Squash and merge" (the most common team default) collapses the whole PR into one clean commit on main; "Rebase and merge" replays them individually. Squash is why messy WIP commits on your branch are fine — they vanish at the gate.
- An AI reviewer may get there first. Many repos auto-request a review from GitHub Copilot (or a similar bot). Read it like a helpful-but-junior teammate: it only ever leaves comments — it never counts toward the required human approval, and it's sometimes wrong. Push back when it is.
main. If your push to main is rejected at work, that's not an error — that's
the process working.Writing a good PR description can feel tedious, but AI tools can help with that too:
After the Merge: Leave the Campsite Clean
git switch main
git pull # Bring the merged work home
git branch -d feature/my-new-idea # Delete the merged branch (-d is safe:
# it refuses if work isn't merged)
git fetch --prune # Drop tracking refs for branches deleted on GitHub(GitHub can auto-delete the remote branch on merge — repo Settings → General → "Automatically delete head branches." Turn it on; nobody misses stale branches.)
You don't even need to leave VS Code to create a PR. Install the GitHub Pull Requests extension and you can create PRs, review diffs, add comments, approve, and merge -- all without opening your browser:
Try It: Branch, Commit, and Push
git push in the playground updates a simulated remote — try git remote -v to see it.Loading playground...
"Push this branch and create a pull request with a good description"
"Create a PR from this branch to main, summarizing all the changes we made"
Loading challenge...