What Are Git Branches and Pull Requests? A Vibe Coder's Guide to Not Breaking Everything

Why AI Coders Need to Know This

If you've used Cursor, Claude Code, or any AI coding agent for more than a few hours, you've probably seen messages like:

• "I'll create a branch for this feature."
• "I've pushed the changes and opened a pull request."
• "Let me merge this into main."

If those phrases make you nod along while secretly panicking — you're not alone. Most vibe coders learn what Git is pretty quickly, but branches and pull requests feel like they belong to "real developers." They don't. They belong to anyone who doesn't want to accidentally destroy their working app.

Here's the reality: AI coding agents use branches and pull requests constantly. Claude Code creates feature branches by default. GitHub Copilot Workspace generates PRs automatically. GitHub Actions run automated tests every time a PR is opened. If you don't understand this workflow, you're flying blind while your AI co-pilot makes decisions about your codebase.

You don't need to become a Git expert. But you need to know enough to understand what your AI is doing, spot when it's doing something wrong, and fix problems when they happen. That's exactly what this guide covers.

Real Scenario: "I'll Create a Branch for This Feature"

Picture this: you're building a web app with Claude Code. Your landing page works perfectly. Users can sign up, log in, and see their dashboard. Everything is stable.

Now you want to add a new feature — a notification system. You tell Claude Code: "Add a notification bell to the dashboard that shows unread messages."

Without understanding this workflow, you might panic when you check your live app and the notification bell isn't there. You might think Claude failed. In reality, it did the professional thing — it kept your working code safe while building something new in isolation.

What AI Generated: The Commands Behind the Workflow

When Claude Code (or any AI tool) says "I'll create a branch," here's what's actually running under the hood. Let's trace through a real workflow:

# Step 1: Make sure you have the latest code
git pull origin main

# Step 2: Create a new branch AND switch to it
git checkout -b feature/notifications
# Output: Switched to a new branch 'feature/notifications'

# What just happened:
# - Git created a copy of your main branch
# - You're now working on that copy
# - Any changes you make will ONLY affect this branch

# Step 3: AI builds the feature (modifies/creates files)
# ... Claude Code edits 6 files, creates 2 new ones ...

# Step 4: Stage all the changes
git add .

# Step 5: Commit with a descriptive message
git commit -m "feat: add notification bell with unread message count"

# Step 6: Push the branch to GitHub
git push origin feature/notifications
# Output: remote: Create a pull request for 'feature/notifications' on GitHub

# Step 7: Create a pull request (via GitHub CLI or GitHub.com)
gh pr create --title "Add notification system" \
  --body "Adds a notification bell to the dashboard showing unread messages"
# Output: https://github.com/your-username/your-app/pull/42

That URL at the end? That's your pull request. It's a page on GitHub where you (and anyone you work with) can review every single change before it touches your main codebase.

Let's break down what each of these concepts actually means.

Understanding Branches: Your Code's Safety Sandbox

A branch is a parallel version of your project that exists alongside your main code without affecting it. That's the entire concept. It's not more complicated than that.

The Construction Analogy

Think of it like a construction project. Your main branch is the finished building that people are already living in. You wouldn't rip out the kitchen to install new cabinets while the family is cooking dinner. Instead, you'd:

1. Build a mockup of the new kitchen design in the garage (create a branch)
2. Test everything — does the plumbing work? Do the doors open right? (write and test code)
3. Once you're satisfied, install it in the actual house (merge the branch)

If the mockup doesn't work out? You haven't touched the real kitchen. Throw away the mockup and start over. Zero damage done.

How Branches Actually Work

Every Git repository starts with one branch, usually called main (older projects may call it master). This is your production branch — the version of your code that works, that's deployed, that users see.

When you create a new branch, Git doesn't actually copy all your files. It creates a pointer that says "start from here and track changes separately." This is why creating a branch is instant, even for huge projects — Git is incredibly efficient.

Essential Branch Commands

# See all your branches (current one has a * next to it)
git branch
# Output:
#   * main
#   feature/notifications
#   fix/login-bug

# Create a new branch and switch to it
git checkout -b feature/new-dashboard
# Modern alternative:
git switch -c feature/new-dashboard

# Switch between existing branches
git checkout main
# Or: git switch main

# Delete a branch you're done with
git branch -d feature/notifications
# (Only works if the branch has been merged)

When you switch branches, your files literally change. Run git checkout main and your notification code disappears. Run git checkout feature/notifications and it's back. Git is swapping between parallel versions of your project instantly.

Understanding Pull Requests: The Code Review Checkpoint

A pull request (PR) is a formal request to merge one branch into another — usually your feature branch into main. It's called a "pull request" because you're asking the main branch to pull in your changes.

But a PR is much more than a merge button. It's a review process. Here's what a pull request gives you:

Why PRs Matter for Solo Vibe Coders

You might be thinking: "I work alone. Why do I need to review my own code?"

Because you're not working alone — you're working with AI. And AI makes mistakes. A pull request forces a pause between "AI wrote code" and "that code is live in production." That pause is where you catch:

• Files the AI changed that it shouldn't have
• Hardcoded API keys or passwords the AI left in the code
• Logic that looks right but will break under real-world conditions
• Changes to critical files (like database schemas) that need extra scrutiny

That statistic applies to human-written code. With AI-generated code — where you may not fully understand every line — code review through PRs becomes even more critical.

The Complete Workflow: Branch to Merge

Here's the full lifecycle, from start to finish. This is the workflow that professional development teams use every single day — and it's exactly what your AI tools are doing:

Step 1: Create a Branch

# Always start from an up-to-date main branch
git checkout main
git pull origin main

# Create your feature branch
git checkout -b feature/user-profiles

Why: You want your branch to start from the latest version of main, not from an outdated version.

Step 2: Build Your Feature

This is where you (and your AI tools) do the actual work. Write code, create files, modify components. Everything happens on your feature branch — main stays untouched.

Step 3: Commit Your Changes

# See what changed
git status
git diff

# Stage and commit
git add .
git commit -m "feat: add user profile page with avatar upload"

Pro tip: Make small, frequent commits rather than one giant commit at the end. If something breaks, you can pinpoint exactly which commit caused the problem.

Step 4: Push to GitHub

# First time pushing this branch:
git push -u origin feature/user-profiles

# Subsequent pushes:
git push

The -u flag links your local branch to the remote one so future pushes are simpler.

Step 5: Open a Pull Request

Go to your repository on GitHub. You'll see a banner saying "feature/user-profiles had recent pushes" with a green "Compare & pull request" button. Click it. Or use the command line:

gh pr create --title "Add user profile page" \
  --body "Adds a profile page where users can update their name and upload an avatar."

Step 6: Review the Changes

On the PR page, click the "Files changed" tab. Read through every change. Ask yourself:

• Do I understand what each change does?
• Did the AI change files I didn't expect?
• Are there any hardcoded values that should be environment variables?
• Does the logic make sense?

Step 7: Merge

Once you're satisfied, click the green "Merge pull request" button on GitHub. Your feature branch's changes are now part of main.

# After merging, clean up locally:
git checkout main
git pull origin main
git branch -d feature/user-profiles

That's it. Seven steps. Branch, build, commit, push, PR, review, merge. Every feature. Every time. It sounds like a lot of steps, but after doing it twice, it becomes second nature — and your AI tools handle most of it automatically.

What AI Gets Wrong About Branches and PRs

AI tools are getting better at Git workflows every month, but they still make predictable mistakes. Here's what to watch for:

2. Creating branches from the wrong base. Sometimes AI creates a branch from another feature branch instead of main. This means your new branch includes unfinished, unreviewed code from the other feature. Check with git log --oneline to see your branch's history.

3. Force pushing without warning. git push --force overwrites the remote branch's history. If anyone else has pulled that branch, their copy is now out of sync. AI tools sometimes suggest force pushing when a regular push fails. Never force push to main. On feature branches, it's usually okay but be aware of what it does.

4. Giant, unfocused PRs. AI might build three features on one branch and create a single PR with 2,000 lines of changes. That's nearly impossible to review. Good PRs are small and focused — one feature, one fix, one improvement per PR.

5. Meaningless commit messages. AI-generated messages like "update files" or "fix stuff" tell you nothing when you're reading the history six months later. Insist on descriptive messages: feat: add email validation to signup form.

How to Debug with AI: Merge Conflicts and Branch Cleanup

The two most common problems you'll hit with branches are merge conflicts and branch management chaos. Here's how to handle both with your AI tools.

Resolving Merge Conflicts

A merge conflict happens when two branches change the same lines in the same file. Git doesn't know which version you want, so it marks the conflict and asks you to decide:

<<<<<<< HEAD
  <h1>Welcome to Your Dashboard</h1>
=======
  <h1>Welcome Back, {user.name}!</h1>
>>>>>>> feature/user-profiles

The section between <<<<<<< HEAD and ======= is what's currently on main. The section between ======= and >>>>>>> is what's on your feature branch.

To resolve it: Delete the conflict markers, keep the version you want (or combine both), save the file, and commit:

# After manually editing the file to resolve the conflict:
git add .
git commit -m "resolve: merge conflict in dashboard header"

AI can help here. Copy the conflicting section and paste it into Claude or Cursor with: "Here's a merge conflict. The HEAD version is the current dashboard header. The feature branch adds personalized greetings. I want to keep the personalized version but also keep the existing styling."

Branch Cleanup

After a few weeks of active development, you might end up with a dozen old branches cluttering your repo. Here's how to clean up:

# See all branches (local)
git branch
# Output:
#   * main
#   feature/notifications (merged 2 weeks ago)
#   fix/login-bug (merged last week)
#   experiment/dark-mode (abandoned)

# Delete merged branches
git branch -d feature/notifications
git branch -d fix/login-bug

# Force-delete an unmerged branch you don't need
git branch -D experiment/dark-mode

# Delete remote branches that no longer exist locally
git remote prune origin

# See remote branches
git branch -r

You can ask your AI: "List all my merged branches that are safe to delete" — it will run the right commands and give you a clean list.

Tool-Specific Tips

Branch Naming Conventions That Keep You Sane

Good branch names make your project history readable at a glance. Here's the convention most teams (and AI tools) follow:

# Features
feature/user-authentication
feature/notification-system
feature/dark-mode

# Bug fixes
fix/login-redirect-loop
fix/missing-avatar-fallback

# Experiments (might not ship)
experiment/new-checkout-flow

# Chores (maintenance, refactoring)
chore/update-dependencies
chore/clean-up-unused-components

The prefix (feature/, fix/, experiment/) tells you what kind of change it is. The description after the slash tells you what specifically changed. When you look at your branch list or PR history, you can instantly understand what each one is about.

When to Branch and When Not To

Not every change needs a branch. Here's a practical guide:

When in doubt, create a branch. The cost is zero (one command, takes half a second), and the safety benefit is enormous. As Chuck says: "You don't skip the hard hat because the ceiling looks solid. You wear it every time."

How Branches and PRs Connect to Deployment

Here's where it all comes together with modern development workflows. When you merge a pull request on GitHub, you can configure automatic deployments. Platforms like Vercel, Netlify, and Railway watch your main branch. The moment a PR is merged into main, they automatically build and deploy your updated app.

This means:

1. You build a feature on a branch
2. You open a PR and review the changes
3. You merge the PR
4. Your app automatically updates in production

No manual file uploads. No FTP. No copying and pasting. The PR merge is the deployment trigger. This is called continuous deployment, and GitHub Actions is often what powers it.

Many platforms also create preview deployments for every PR — a temporary URL where you can see and test the feature before merging. This means you can click a link, see your notification bell working on a test site, confirm it looks right, and then merge with confidence.

FAQ