GitVibes / Branching & PRs
Part 3

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.

Important
The most important rule in collaborative software development: you never, ever work directly on the 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.

Branches let you experiment without risking the stable codebase
Note
The Problem: You want to try a new feature or a massive AI-driven refactor. Before you write a single line or prompt, create a safe, isolated branch.

First, make sure you're on main and it's up to date. Then create your branch:

Create and switch to a new branch
git switch -c feature/my-new-idea
# Older equivalent: git checkout -b feature/my-new-idea

In 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:

VS Code
Click the branch name in the bottom-left corner to switch branches or create 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:

VS Code
The branch Quick Pick lets you create, switch, or check out branches without touching the terminal.
Tip
Your new branch starts exactly where 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.
Warning
Common mistake — committed to main by accident? Don't panic. If you haven't pushed yet, the fix is simple: create the feature branch (your commits come with it), then switch back to main and 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

The playground starts with a payment commit on main that should be on a feature branch. Create the branch, then reset main with git reset --hard HEAD~1.
Move Commit to Feature Branch

Loading playground...

Vibe it

"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.

Fetch checks for updates, pull downloads them, push shares your work
Note
The Problem: You've been working on your feature branch for a few days. Your teammates have merged their work into 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)

Two-step controlled sync
git fetch origin        # Download new commits (doesn't apply them)
git merge origin/main   # Merge the updates into your branch

Option 2: The "Easy" Sync (pull)

One-step sync
git pull origin main    # Fetch + merge in one command
Tip
As a best practice, git fetch first to see what's coming before merging. git pull is just a "black box" shortcut.
Important
When plain 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:

VS Code
The incoming/outgoing section shows exactly which commits you need to pull and which you'll push.

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:

VS Code
The Sync Changes button combines pull + push in one click. The numbers show incoming (↓) and outgoing (↑) commit counts.

Try It: Fetch and Merge Remote Updates

The playground simulates a remote called origin — no real network calls. After git fetch origin, run git log --oneline --all to see both local and remote branches.
Sync with Remote

Loading playground...

Vibe it

"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."

Pull requests are the quality gate between your branch and production
Note
The Problem: Your feature is complete, tested, and ready to be merged into 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:

Push your branch to the remote
git push -u origin feature/my-new-idea
# -u links your local branch to the remote branch

Then on GitHub, you'll see a yellow banner: "feature/my-new-idea had recent pushes. Compare & pull request." Click it to create your PR.

Important
A Pull Request is a request for discussion. It is the formal, auditable gate where your human teammates review your AI-generated code, suggest changes, and ultimately "sign off" before it enters 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.
Note
Teams enforce all of this with rulesets (repo Settings → Rules) — require a PR, require passing checks, require an approval before anything reaches 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:

Tip
AI Integration: GitHub Copilot can write your PR descriptions by summarizing your commits. Claude Code can even automate the PR creation process.

After the Merge: Leave the Campsite Clean

Post-merge hygiene
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:

VS Code
Create Pull Requests directly in VS Code with the GitHub Pull Requests extension. AI can even generate the PR description for you.

Try It: Branch, Commit, and Push

git push in the playground updates a simulated remote — try git remote -v to see it.
Branching Workflow

Loading playground...

Vibe it

"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"

Challenge: Branch Before You Build

Loading challenge...