How to Use Git Branches: A Practical Guide

Quick Answer

A Git branch is a separate, lightweight line of work where you can build a feature without touching your main code. To use branches, create one with git switch -c feature-login, do your work and commit it, then switch to main and run git merge feature-login to combine it. Finally, delete the finished branch with git branch -d feature-login. This "one branch per task" loop keeps main stable and your history clean.

Why Git branches exist

If you are learning Git, branches are the feature that finally makes it click. How to use Git branches comes down to one simple idea: a branch is a separate line of work where you can build, test, and experiment without touching the code everyone else depends on.

Imagine you and three classmates are building a website. One of you is adding a login page, another is fixing the footer, a third is trying a new colour scheme. If everyone edits the same files at the same time, you get chaos. Branches let each person work in their own space and combine the results only when they are ready.

Here is the part that surprises beginners: a branch in Git is not a heavy copy of your project. It is just a lightweight, movable pointer to a commit. Creating one is instant and costs almost nothing, so you can make a branch for every small task without a second thought. The branch you start on is usually called main (older projects call it master).

New to Git entirely? Our free Git course covers commits and repositories first, then branching. This guide assumes you can already make a commit.

Seeing the branches you already have

Before creating anything, look at what you already have. Run:

git branch

You'll see a list of your local branches, with a * marking the one you are currently on:

$ git branch
* main

A brand-new repository has just one branch, main. To see remote branches too (the ones on GitHub or GitLab), add -a for "all":

git branch -a

That's your map. The * always tells you where you are, and that matters because every commit you make lands on the current branch.

Creating a branch and switching to it

Say you want to build a login page. Create a branch and move onto it in one command:

git switch -c feature-login

The -c means "create", and git switch moves you onto the new branch straight away. Run git branch again and you'll see the * has jumped to feature-login. Your new branch starts as an exact copy of wherever you were, so it already contains all of main's code.

The older way: git checkout

You will see a lot of tutorials use checkout instead:

git checkout -b feature-login

This does exactly the same thing. Git split the old, overloaded checkout command into two clearer ones in version 2.23 — git switch for changing branches and git restore for discarding file changes. Both still work, but switch is easier to read, so we'll use it here.

Create now, switch later

If you want to create a branch but stay where you are, use git branch with a name:

git branch feature-login

Then move onto it whenever you're ready with git switch feature-login. Pick short, descriptive names like feature-login, fix-navbar, or bugfix-payment so anyone can tell what a branch is for.

Doing the work on your branch

Now that you're on feature-login, work exactly as you normally would. Edit files, then stage and commit them:

git add .
git commit -m "Add login form and validation"

This commit lands on feature-login only. Here's the reassuring part — switch back to main and look:

git switch main

Your login files disappear from view, because main never changed. Switch back with git switch feature-login and they reappear. Nothing is lost; each branch simply shows its own version of the project. This is exactly why branches are safe to experiment on: if the login idea turns out badly, you can throw away the whole branch and main is untouched.

Merging your feature branch into main

Once the feature works and is committed, it's time to bring it into main. Merging always happens into the branch you're currently on, so first switch to the destination, then merge:

git switch main
git merge feature-login

If nobody else changed main while you were working, Git does a fast-forward merge — it simply slides main forward to include your commits, with no extra merge commit. If main did move on, Git creates a merge commit that ties the two histories together. Either way, main now contains your login page.

Sometimes Git can't combine the two automatically because the same lines changed on both sides. That's a merge conflict. Git pauses and marks the clashing spots in the files so you can choose what to keep; you then git add the fixed files and commit. If you'd like to go deeper on how merging works and how it compares to rebasing, read our guide on Git merge vs rebase.

Deleting a branch when you're done

After a branch is merged, you don't need it any more. Keeping dozens of old branches around just clutters your list, so delete it:

git branch -d feature-login

The lowercase -d is the safe option — Git refuses to delete a branch whose commits haven't been merged, protecting you from losing work by accident. If you're certain you want to throw away an unmerged branch (an experiment that didn't pan out), use the capital -D to force it:

git branch -D feature-login

Deleting a branch only removes the pointer, not the commits behind it — once merged, those commits live safely in main. If you also pushed the branch to a remote, delete the remote copy too:

git push origin --delete feature-login

How to use Git branches: the full workflow

Put all the pieces together and the everyday branch workflow is just six steps:

# 1. Start from an up-to-date main
git switch main
git pull

# 2. Create a branch for your task
git switch -c feature-login

# 3. Do the work and commit it
git add .
git commit -m "Add login form and validation"

# 4. Bring the latest main into your branch (optional but tidy)
git merge main

# 5. Merge your finished feature into main
git switch main
git merge feature-login

# 6. Delete the branch you no longer need
git branch -d feature-login

Step 4 is optional, but pulling the latest main into your branch before the final merge means you sort out any conflicts on your own branch rather than on main. Once you've run this cycle a few times, it becomes second nature — one branch per task, merge, delete, repeat.

Common gotchas and our recommendation

A few things trip up almost every beginner:

• Uncommitted changes can block a switch. If you try to change branches with unsaved edits that would be overwritten, Git stops you. Either commit your work first, or park it temporarily with git stash and bring it back later with git stash pop.
• Don't work directly on main. Treat main as the stable, always-working version. Do your building on branches and let main receive only finished, tested work.
• Branch from an up-to-date main. Run git pull on main before creating a branch, so you start from your team's latest code and avoid needless conflicts later.
• Check where you are before committing. A quick git branch or git status confirms the * is on the branch you think it is — committing to the wrong branch is a common mix-up.

Our recommendation: make a habit of one short-lived branch per task. Use git switch -c to create it, commit often, merge it into main when it's done, and delete it straight away. This keeps your history clean and your main branch reliable. Practise the whole cycle hands-on in the free Priodemy Git course, and keep our Git commands cheat sheet nearby for quick reference.

Frequently Asked Questions