Branch-Based Development

Say you're writing a book. Would you make big changes right on top of your final draft? Probably not... because what happens when those changes don't pan out? That's the whole reason developers use branches.

A branch is like a separate copy of your project where you can make changes without touching the main version. It's one of the most important ideas in all of Git, so it's worth getting comfy with.

Why Work in Branches?#

Here's a picture that helps. Your main project is a tree trunk. When you want to try something new, you grow a branch off that trunk and work on it as much as you like. If it turns out great, you merge it back into the trunk. If it flops, you just cut the branch off. The trunk stays safe either way.

So why do branches matter so much?

• Keep main clean - Your main branch always has working code
• Try things safely - Experiment without breaking anything
• Work together - Lots of people can build different features at the same time
• Review changes - Other folks can look at your branch before it joins main

What is a Feature Branch?#

A feature branch is dead simple. One branch for one feature, and that's it.

Let's say you want to add dark mode to your website. Here's how it'd go.

1. Create a new branch called something like add-dark-mode
2. Do all your work on that branch
3. When it's done and tested, merge it into main

Step 1. Create a Feature Branch#

You start by making a new branch from main.

git checkout -b add-dark-mode

That creates the new branch and switches you over to it.

Step 2. Do Your Work#

Make all your changes on this branch. Commit as many times as you want. This branch is your lil workshop.

Step 3. Merge When Ready#

Once the feature is finished and tested, you merge it back into main. Usually that happens through a pull request (more on those later).

Branch Naming Conventions#

Good branch names help everybody understand what's going on in a project. Most teams stick to naming patterns like these.

Some teams skip the prefix entirely and go with descriptive names like add-dark-mode or fix-login-bug. Either way works fine. What REALLY matters is staying consistent with your team.

Common Branch Commands#

Here are the Git commands you'll lean on most with branches.

git branch

Lists all your local branches. The one with the asterisk (*) is the branch you're on.

git checkout -b new-branch-name

Creates a new branch and switches to it. It's a shortcut that rolls two commands into one.

git checkout main

Switches back to the main branch (or whatever branch you name).

git branch -d branch-name

Deletes a branch you don't need anymore. If you haven't merged it yet, Git refuses and tells you so, which is a nice lil safety net.

A Real Example#

Let's walk through a real scenario. You're building a recipe website and you want to add a search feature.

Step 1. Start Fresh#

First, make sure you're on main and it's up to date.

git checkout main
git pull

Step 2. Create Your Branch#

Make a feature branch for search.

git checkout -b feature/recipe-search

Step 3. Make Your Changes#

Build the search feature and commit your work as you go.

git add .
git commit -m "Add search bar to header"

Keep working and committing. Every commit needs its changes staged with git add first, so the pattern repeats.

git add .
git commit -m "Add search results page"
 
git add .
git commit -m "Connect search to recipe database"

Step 4. Push Your Branch#

Push your branch up to GitHub so other people can see it.

git push -u origin feature/recipe-search

The -u flag sets up tracking, so every push after this one is simpler.

Step 5. Create a Pull Request#

Over on GitHub, open a pull request to merge your branch into main. Your team reviews it, and once it's approved, in it goes!

When to Create a New Branch#

Here's a solid rule of thumb. Make a new branch any time you're starting something new, like these.

• Adding a new feature
• Fixing a bug
• Trying an experiment
• Making any change you might want to undo

Small, focused branches beat big messy ones every time. If your branch is doing ten different things, it's too big, so break it up.

TL;DR#

• Branches let you work safely without touching the main project
• The main branch should always hold working, tested code
• Feature branches follow one simple pattern, one branch for one feature
• Use clear naming conventions like feature/, bugfix/ or hotfix/
• Small, focused branches are easier to review and merge
• Always make a branch before you start new work

What's Next?#

What if you need to work on two branches at the exact same time? Maybe you're halfway through a feature and somebody needs you to review their code. Next lesson we'll get into worktrees, a handy way to work on multiple branches at once...