GIT WORKFLOWS / LESSON 01

Branch-Based Development.

Organizing work with branches

Written by Andrew Lee JenkinsPublished Oct 5, 202612 min readFree lesson

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.

Create a new branch called something like add-dark-mode
Do all your work on that branch
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.

Example

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.

Prefix	What it means	Example
`feature/`	A new feature	`feature/user-login`
`bugfix/`	Fixing a bug	`bugfix/broken-button`
`hotfix/`	Urgent fix for production	`hotfix/security-patch`
`docs/`	Documentation changes	`docs/update-readme`
`test/`	Adding or fixing tests	`test/add-login-tests`

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.

Example

git branch

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

Example

git checkout -b new-branch-name

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

Example

git checkout main

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

Example

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.

Example

git checkout main
git pull

Step 2. Create Your Branch

Make a feature branch for search.

Example

git checkout -b feature/recipe-search

Step 3. Make Your Changes

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

Example

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.

Example

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.

Example

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

Loading the lesson…

Loading activities…