Branches: How to Break Things Without Breaking Things

You have a working scraper. It scrapes 1,000 products daily. No errors. It's been running smoothly for two weeks.

Your boss asks: "Can we add image downloading? Just test it first, don't break the working scraper."

You have a problem. You need to modify the scraper to add images. But if you edit the working code directly, you might break it. Then nothing works. Your daily scraping stops. Your boss is unhappy.

You could make a copy of the entire project folder. scraper_v1, scraper_v2, scraper_with_images. Work on the copy. If it works, copy the changes back to the original. If it breaks, delete the copy.

This gets messy fast. Which folder has the latest changes? Did you edit both? Which one should you deploy?

This is exactly why Git has branches.

A branch is a parallel version of your code. You create a branch called "add-images". Work on it. Break things. Fix them. Test everything. When it works perfectly, you merge it back into your main code.

Your main code stays untouched. Running smoothly. While you experiment in a separate branch. If your experiment fails, just delete the branch. The main code never knew it happened.

Branches sound complicated. They're not. Think of them as save files in a video game. You have your main save (the one you care about). You create a test save to try risky strategies. If it works, great. If not, load your main save and try again.

Let me show you.

---

What Branches Actually Are (The Simple Version)

Forget everything you've heard about directed acyclic graphs and commit trees.

A branch is just a label pointing to a commit.

That's it.

You've been using a branch this whole time. It's called main (or master in older Git).

When you make commits, they go on the main branch. It's the default. The one that exists automatically.

Creating a new branch:

git branch feature-images

This creates a new label called feature-images pointing to the same commit as main.

Now you have two branches:

• main - your working code
• feature-images - a copy where you'll add images

When you switch to the new branch and make commits, only that branch moves forward. main stays where it was.

Think of it like this:

Before branching:
main → commit1 → commit2 → commit3

After creating branch:
main → commit1 → commit2 → commit3
feature-images → commit1 → commit2 → commit3

After committing on feature-images:
main → commit1 → commit2 → commit3
feature-images → commit1 → commit2 → commit3 → commit4 → commit5

main hasn't changed. feature-images has new commits. They exist in parallel.

Later, you can merge feature-images back into main. Then main gets commits 4 and 5 too.

---

Your First Branch

Let's create a branch and work on it.

Step 1: Check Current Branch

git branch

Output:

* main

The * shows which branch you're on. You're on main.

Step 2: Create New Branch

git branch add-error-handling

Check branches again:

git branch

Output:

  add-error-handling
* main

You created a branch but you're still on main.

Step 3: Switch to New Branch

git checkout add-error-handling

Output:

Switched to branch 'add-error-handling'

Check where you are:

git branch

Output:

* add-error-handling
  main

The * moved. You're now on the new branch.

Shortcut: Create and switch in one command:

git checkout -b add-error-handling

This creates the branch AND switches to it. Use this instead of separate commands.

Step 4: Make Changes on the Branch

# Edit your code
echo "try:" >> scraper.py
echo "    # scraping code" >> scraper.py
echo "except Exception as e:" >> scraper.py
echo "    print(f'Error: {e}')" >> scraper.py

# Commit on this branch
git add scraper.py
git commit -m "Added error handling to scraper"

Step 5: Switch Back to Main

git checkout main

Check your file:

cat scraper.py

The error handling code is gone! Your file looks like it did before.

This is the magic. The changes exist on add-error-handling branch. They don't exist on main. You can switch back and forth.

Step 6: View Branches with Commits

git log --oneline --all --graph

Output:

* d4e5f6g (add-error-handling) Added error handling to scraper
| 
* c3d4e5f (HEAD -> main, origin/main) Last commit on main
* b2c3d4e Previous commit
* a1b2c3d Initial commit

You can see the branches diverged. add-error-handling has one extra commit.

---

Merging Branches

Your feature works. You tested it on the branch. Time to bring it into main.

Step 1: Switch to Main

Always merge INTO the branch you're on. You want the changes IN main, so switch to main first.

git checkout main

Step 2: Merge the Feature Branch

git merge add-error-handling

Output:

Updating c3d4e5f..d4e5f6g
Fast-forward
 scraper.py | 4 ++++
 1 file changed, 4 insertions(+)

"Fast-forward" means: main just moved forward to where add-error-handling was. No conflicts. Clean merge.

Check your file:

cat scraper.py

The error handling code is now in main!

Step 3: Delete the Feature Branch (Optional)

You don't need it anymore. The changes are in main.

git branch -d add-error-handling

Output:

Deleted branch add-error-handling (was d4e5f6g).

Check branches:

git branch

Output:

* main

Back to one branch. Clean.

---

The Feature Branch Workflow

This is how professionals work with branches.

Pattern:

# Start on main with latest code
git checkout main
git pull

# Create feature branch
git checkout -b feature-name

# Work on the feature (multiple commits okay)
git add .
git commit -m "Implemented X"
git add .
git commit -m "Fixed bug in X"
git add .
git commit -m "Added tests for X"

# Switch back to main
git checkout main

# Merge the feature
git merge feature-name

# Delete the branch
git branch -d feature-name

# Push to GitHub
git push

Real Example: Adding Login to Scraper

# Start fresh
git checkout main
git pull

# Create login branch
git checkout -b add-login

# Implement login (first attempt)
echo "def login(username, password):" >> scraper.py
echo "    # login logic" >> scraper.py
git add scraper.py
git commit -m "Added basic login function"

# Test it, find bugs, fix them
echo "    # improved login logic" >> scraper.py
git add scraper.py
git commit -m "Fixed login bug with special characters"

# Add error handling
echo "    # error handling" >> scraper.py
git add scraper.py
git commit -m "Added error handling to login"

# Feature is done, merge it
git checkout main
git merge add-login

# Clean up
git branch -d add-login

# Push to GitHub
git push

You made three commits on the branch. They all merged into main together. Your main branch history shows a clean progression.

---

Handling Merge Conflicts (The Scary Part)

Sometimes Git can't merge automatically. This happens when:

• You changed the same line in both branches
• You deleted a file in one branch, edited it in another
• Two branches modified the same section differently

Creating a Conflict (Intentionally)

Let's simulate a conflict to learn how to fix it.

On main branch:

git checkout main

# Edit scraper.py
echo "print('Version A')" > scraper.py

git add scraper.py
git commit -m "Main branch changes"

Create and switch to new branch:

# Branch from BEFORE the main change
git checkout HEAD~1
git checkout -b feature-conflict

# Edit the SAME LINE differently
echo "print('Version B')" > scraper.py

git add scraper.py
git commit -m "Feature branch changes"

Try to merge:

git checkout main
git merge feature-conflict

Output:

Auto-merging scraper.py
CONFLICT (content): Merge conflict in scraper.py
Automatic merge failed; fix conflicts and then commit the result.

Git can't decide which version to keep. You have to choose.

Resolving the Conflict

Open scraper.py:

<<<<<<< HEAD
print('Version A')
=======
print('Version B')
>>>>>>> feature-conflict

What this means:

• <<<<<<< HEAD - Start of your current branch's version (main)
• ======= - Separator
• >>>>>>> feature-conflict - End of the other branch's version

You need to:

1. Decide which version to keep (or combine both)
2. Remove the conflict markers
3. Save the file
4. Commit the resolution

Option 1: Keep Version A

print('Version A')

Option 2: Keep Version B

print('Version B')

Option 3: Keep Both

print('Version A')
print('Version B')

Option 4: Write Something New

print('Combined version C')

Let's keep Version A:

# Edit file to just have:
print('Version A')

# Save and close

# Tell Git the conflict is resolved
git add scraper.py

# Commit the merge
git commit -m "Resolved merge conflict, kept Version A"

Done! The merge is complete.

Avoiding Conflicts

Best practices:

1. Pull before branching - Start with latest code
2. Work on different files - Multiple people editing different parts
3. Merge often - Don't let branches drift apart for weeks
4. Communicate with team - "I'm editing scraper.py today"

Most conflicts are easy to resolve. Don't panic when you see one.

---

Visualizing Branches

Understanding branches visually helps.

Simple Branch Example

Initial state:
main → A → B → C

Create branch 'feature':
main    → A → B → C
feature → A → B → C (same commits)

Commit on feature:
main    → A → B → C
feature → A → B → C → D → E

Merge feature into main:
main → A → B → C → D → E
(feature branch can be deleted)

Divergent Branches

Initial:
main → A → B → C

Create branch:
main    → A → B → C
feature → A → B → C

Commit on both:
main    → A → B → C → D
feature → A → B → C → E → F

Merge:
main → A → B → C → D → (merge commit)
                  ↓      ↑
feature → A → B → C → E → F

When branches diverge, merging creates a "merge commit" that combines both histories.

Viewing Your Branch Graph

git log --graph --oneline --all

Output:

* d4e5f6g (HEAD -> main) Merge feature into main
|\  
| * c3d4e5f (feature) Feature commit 2
| * b2c3d4e Feature commit 1
* | a1b2c3d Main commit after branching
|/  
* 9a8b7c6 Commit before branching

This shows how branches split and merge.

---

Working with Branches on GitHub

Branches work on GitHub too.

Pushing a Branch to GitHub

# Create and work on branch locally
git checkout -b add-pagination
echo "# pagination code" >> scraper.py
git add scraper.py
git commit -m "Added pagination support"

# Push branch to GitHub
git push -u origin add-pagination

The -u flag sets up tracking. After this, you can just use git push without arguments.

On GitHub: Visit your repo. You'll see a banner: "add-pagination had recent pushes."

Pulling Branch Changes from GitHub

Someone else pushed changes to a branch. You want them.

# See all branches (including remote ones)
git branch -a

# Switch to the remote branch
git checkout add-pagination

# Pull latest changes
git pull

Deleting Remote Branches

# Delete local branch
git branch -d add-pagination

# Delete branch on GitHub
git push origin --delete add-pagination

---

Pull Requests (The GitHub Way to Merge)

Pull requests (PRs) are GitHub's interface for merging branches.

Why use pull requests instead of merging locally?

1. Code review - Others can review your changes before merging
2. Discussion - Comment on specific lines, ask questions
3. Testing - Automated tests run on the branch
4. History - See what was discussed during merge
5. Safety - Main branch is protected, only approved PRs merge

Creating a Pull Request

Step 1: Push Your Branch

git checkout -b improve-error-messages
echo "print('Better error message')" >> scraper.py
git add scraper.py
git commit -m "Improved error messages for clarity"
git push -u origin improve-error-messages

Step 2: Create PR on GitHub

1. Go to your repo on GitHub
2. You'll see: "Compare & pull request" button
3. Click it
4. Title: "Improve error messages"
5. Description: "Changed error messages to be more descriptive and helpful"
6. Click "Create pull request"

Step 3: Review and Merge

For your own projects:

1. Review the changes (see the diff)
2. Click "Merge pull request"
3. Click "Confirm merge"
4. Optionally: Delete the branch

The changes are now in main on GitHub.

Step 4: Update Local Main

git checkout main
git pull

Your local main now has the merged changes.

Why This Workflow Matters

In teams, this is how everyone works:

1. You create a branch
2. You push it to GitHub
3. You create a pull request
4. Teammates review your code
5. They approve (or request changes)
6. You merge when approved
7. Everyone pulls the updated main

Even solo, PRs give you:

• A place to document why you made changes
• A chance to review your own code
• A clean merge history

---

Branch Naming Conventions

Good branch names describe what you're working on.

Good Names

Features:

• feature/add-login
• feature/image-download
• add-pagination

Bug fixes:

• fix/crash-on-invalid-url
• bugfix/price-parsing
• fix-memory-leak

Improvements:

• improve/error-handling
• refactor/scraper-logic
• optimize-database-queries

Experiments:

• experiment/new-parser
• test/alternative-approach
• spike/selenium-integration

Bad Names

• branch1, branch2, new-branch
• test, temp, asdf
• johns-branch, fixes
• my-changes, updates

Use descriptive names. Future you will thank past you.

---

Multiple Branches Simultaneously

You can have many branches for different features.

Example: Working on Three Features

# Feature 1: Login
git checkout -b add-login
# (work on login)
git commit -m "Implemented login"

# Feature 2: Image download (pause login work)
git checkout main
git checkout -b add-images
# (work on images)
git commit -m "Added image downloading"

# Feature 3: Error handling (pause images)
git checkout main
git checkout -b improve-errors
# (work on errors)
git commit -m "Better error messages"

You now have three branches:

git branch

Output:

  add-images
  add-login
* improve-errors
  main

Finish error handling first:

git checkout main
git merge improve-errors
git branch -d improve-errors
git push

Back to images:

git checkout add-images
# (continue work)

Switch context anytime:

# Jump between features as needed
git checkout add-login    # Work on login
git checkout add-images   # Work on images
git checkout main         # Check production code

Each branch is independent. Changes in one don't affect others.

---

Recovering from Branch Mistakes

Mistake 1: Committed to Wrong Branch

You meant to create a branch but committed to main by accident.

Fix:

# Create branch from current position
git branch feature-branch

# Reset main to previous commit
git reset --hard HEAD~1

# Switch to new branch (has your commit)
git checkout feature-branch

Your commit is now on the feature branch, not main.

Mistake 2: Want to Undo Branch Merge

You merged a branch but it broke things.

Fix:

# See recent commits
git log --oneline

# Find the commit BEFORE the merge
# Let's say it's abc123

# Reset to before merge
git reset --hard abc123

The merge is undone. The branch still exists if you want to fix it and merge again.

Mistake 3: Deleted Branch Too Early

You deleted a branch but needed it again.

Fix:

# Find the last commit on that branch
git reflog

# You'll see something like:
# d4e5f6g HEAD@{3}: commit: Last commit on deleted branch

# Recreate the branch at that commit
git branch recovered-branch d4e5f6g

The branch is back!

---

Branch Strategies

Different workflows for different needs.

Solo Developer

Simple strategy:

• main - production code, always working
• Feature branches - one per feature
• Merge when feature is done
• Delete branch after merge

git checkout -b add-feature
# (work)
git checkout main
git merge add-feature
git branch -d add-feature

Small Team (2-5 people)

Feature branch strategy:

• main - production code
• Feature branches - one per developer per feature
• Pull requests for review
• Merge after approval

git checkout -b johns-login-feature
git push -u origin johns-login-feature
# (create PR on GitHub)
# (teammate reviews)
# (merge via GitHub)

Larger Projects

Git Flow strategy:

• main - production releases only
• develop - integration branch
• feature/* - feature branches
• release/* - release preparation
• hotfix/* - emergency fixes

More complex. Not needed for most projects.

---

Real Example: Building a Scraper with Branches

Let's build a real scraper using proper branch workflow.

Starting Point

# Clone your repo
git clone https://github.com/yourusername/ecommerce-scraper.git
cd ecommerce-scraper

# Check main branch
git checkout main

Feature 1: Basic Scraping

# Create feature branch
git checkout -b feature/basic-scraping

# Create scraper
cat > scraper.py << 'EOF'
import requests
from bs4 import BeautifulSoup

def scrape_products(url):
    response = requests.get(url)
    soup = BeautifulSoup(response.content, 'html.parser')

    products = []
    for item in soup.select('.product'):
        products.append({
            'name': item.select_one('.name').text,
            'price': item.select_one('.price').text
        })

    return products

if __name__ == '__main__':
    products = scrape_products('https://example.com/products')
    print(f'Found {len(products)} products')
EOF

# Commit
git add scraper.py
git commit -m "Implemented basic product scraping"

# Push and create PR
git push -u origin feature/basic-scraping

On GitHub: Create pull request, review, merge.

Locally:

git checkout main
git pull
git branch -d feature/basic-scraping

Feature 2: Add Data Saving

# New branch from updated main
git checkout main
git pull
git checkout -b feature/save-data

# Add saving functionality
cat >> scraper.py << 'EOF'

import json

def save_products(products, filename='products.json'):
    with open(filename, 'w') as f:
        json.dump(products, f, indent=2)
EOF

# Update main function
# (edit scraper.py to call save_products)

# Commit
git add scraper.py
git commit -m "Added JSON data saving"

# Push and PR
git push -u origin feature/save-data

Merge via GitHub. Update local:

git checkout main
git pull
git branch -d feature/save-data

Feature 3: Error Handling

git checkout main
git pull
git checkout -b feature/error-handling

# Add error handling
# (edit scraper.py)

git add scraper.py
git commit -m "Added comprehensive error handling"
git push -u origin feature/error-handling

Merge via GitHub.

Feature 4: Pagination (Work in Progress)

git checkout main
git pull
git checkout -b feature/pagination

# Start working on pagination
# (edit scraper.py)

git add scraper.py
git commit -m "WIP: Started pagination implementation"

# Realize you need to fix a bug in main first
git checkout main
git checkout -b hotfix/price-parsing

# Fix the bug
# (edit scraper.py)

git add scraper.py
git commit -m "Fixed price parsing for decimal values"
git push -u origin hotfix/price-parsing

Merge hotfix immediately via GitHub.

# Back to pagination
git checkout feature/pagination

# Merge the hotfix into your feature branch
git merge main

# Continue pagination work
# (edit scraper.py)

git add scraper.py
git commit -m "Completed pagination implementation"
git push -u origin feature/pagination

Merge via GitHub.

Your repo now has a clean history of features developed independently and merged when ready.

---

Branch Workflow Checklist

Use this every time you start new work:

Starting a feature:

☐ git checkout main
☐ git pull
☐ git checkout -b feature/descriptive-name

While working:

☐ Make changes
☐ git add .
☐ git commit -m "Clear description"
☐ Repeat until feature is done

Finishing a feature:

☐ git push -u origin feature/descriptive-name
☐ Create pull request on GitHub
☐ Review your own changes
☐ Merge (or get approval first in teams)
☐ git checkout main
☐ git pull
☐ git branch -d feature/descriptive-name

Emergency fix on main:

☐ git checkout main
☐ git checkout -b hotfix/issue-name
☐ Fix the issue
☐ git commit -m "Fix: description"
☐ git push -u origin hotfix/issue-name
☐ Merge immediately
☐ Update all feature branches: git merge main

---

Common Branch Commands Reference

Creating and Switching

# Create branch
git branch branch-name

# Switch to branch
git checkout branch-name

# Create and switch (shortcut)
git checkout -b branch-name

# New syntax (Git 2.23+)
git switch branch-name
git switch -c branch-name  # create and switch

Viewing Branches

# List local branches
git branch

# List all branches (local + remote)
git branch -a

# List with last commit
git branch -v

# See branch history
git log --graph --oneline --all

Merging

# Merge branch-name into current branch
git merge branch-name

# Merge with message
git merge branch-name -m "Merge message"

# Abort merge if conflicts are too complex
git merge --abort

Deleting

# Delete merged branch (safe)
git branch -d branch-name

# Force delete unmerged branch (dangerous)
git branch -D branch-name

# Delete remote branch
git push origin --delete branch-name

Syncing with Remote

# Push branch to GitHub
git push -u origin branch-name

# Push current branch
git push

# Pull branch updates
git pull

# Fetch all branches without merging
git fetch --all

---

What's Next?

You now know how to use branches. You can work on features without breaking main code. You can experiment safely. You understand pull requests.

But you're still working alone. What about:

• Contributing to other people's projects?
• Having multiple people work on the same repo?
• Reviewing code before it merges?
• Managing conflicts when two people edit the same file?

That's collaboration, and it's blog 4.

Blog 4 will cover:

• Forking repositories (making your own copy)
• Pull request workflow for contributions
• Code review best practices
• Working in teams without chaos
• .gitignore (what NOT to commit)
• GitHub Issues and Projects
• Real collaboration scenarios

Collaboration builds on everything you've learned: Git basics, GitHub, and branches. You already know the tools. Now you'll learn to use them with other people.

---

Summary

Branches let you work on features without breaking main code.

Core concepts:

• Branch = parallel version of your code
• main = production code (always working)
• Feature branches = experimental code
• Merge = combine branch back into main

Basic workflow:

git checkout -b feature-name   # Create branch
# (make changes)
git add .
git commit -m "message"
git checkout main              # Back to main
git merge feature-name         # Merge changes
git branch -d feature-name     # Delete branch

With GitHub:

git checkout -b feature-name
# (make changes and commit)
git push -u origin feature-name
# (create pull request on GitHub)
# (merge via GitHub)
git checkout main
git pull

Merge conflicts:

• Happen when same code is edited differently
• Open file, choose which version to keep
• Remove conflict markers
• Commit the resolution

Best practices:

• One feature per branch
• Descriptive branch names
• Merge often (don't let branches drift)
• Delete branches after merging
• Use pull requests for code review

Branches aren't complicated. They're just parallel versions of your code. Create them. Work on them. Merge them. Delete them. That's the whole workflow.

You can now safely experiment without breaking anything.

---

Next up: Blog 4 - "Collaboration: Working with Others Without Chaos"

We'll learn how to contribute to open source, work in teams, review code, and handle the chaos of multiple people editing the same project.

---

Resources:

• Git branching tutorial: https://learngitbranching.js.org
• GitHub pull requests: https://docs.github.com/en/pull-requests
• Git branch documentation: https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell