Beginner's guide to Git branching

So You've Heard You Should "Branch Out" in Git. Here's What That Actually Means.

Hey, welcome back to the BytebaseX blog. If you clicked on this post, chances are you've typed git commit -m "fixed stuff" a hundred times, pushed straight to main, and silently hoped nothing broke. No judgment here. We've all done it. Half our early projects at BytebaseX looked like a demolition derby on the main branch before someone finally said "okay, we need to talk about branching."

So that's what this post is. A plain, no-nonsense walkthrough of Git branching for people who are tired of half-explained tutorials that assume you already know what a "detached HEAD" is (spoiler: even experienced devs panic a little when they see that message).

By the end of this, you'll understand not just the commands, but why branching exists in the first place, and you'll have a mental model that actually sticks instead of fading the moment you close the tab.

The Problem Branching Actually Solves

Let's start with the real problem, because tutorials that jump straight to git branch without explaining why you'd bother are part of the reason branching feels confusing.

Imagine you're working on a small app. It works. It's live. Now you want to add a new feature, say, a dark mode toggle. But here's the catch: what if halfway through building it, you realize it's going to take three days, and meanwhile a client reports a bug that needs fixing today?

If you're working directly on your main codebase (what Git calls the "main" or "master" branch), you're stuck. Your dark mode code is half-written and broken. You can't just pause and fix the bug cleanly because everything is tangled together in the same timeline.

This is the exact situation branching was built for: letting you work on multiple things at once without one messing up the other.

A branch is basically a parallel copy of your project where you can experiment, build, and even break things, without touching the stable version everyone else relies on. Once your work is solid, you merge it back in. If it's not working out, you just delete the branch and nothing was ever at risk.

Think of your main branch as the published, working version of a book. A branch is like a photocopy where you scribble notes, cross things out, and rewrite chapters. Nobody sees the mess. They only see the final draft once you're happy with it and it goes back into the original book.

Why Not Just Save Multiple Copies of Your Folder Instead?

Good question, and honestly, that's what a lot of beginners do before they learn Git. You end up with folders like project-final, project-final-v2, project-final-ACTUAL-final. It works for a day or two, then becomes a nightmare because you lose track of what changed where.

Git branches solve this because they're lightweight and they live inside the same project. You're not duplicating files, you're just telling Git "remember this point, and let me build a separate timeline from here." Switching between timelines takes one command. Comparing them takes one command. Merging them takes one command (usually).

Info: A Git branch isn't a copy of your files sitting somewhere else on disk. It's just a pointer to a specific commit. That's why creating a branch is instant, even on huge projects. There's nothing being duplicated behind the scenes.

Let's Get Our Hands Dirty: Creating Your First Branch

Enough theory. Open your terminal in any Git repository (if you don't have one yet, run git init in an empty folder to create a test project).

First, check what branch you're currently on:

git branch

You'll probably see something like this, with an asterisk showing your current branch:

* main

Now let's create a new branch for that dark mode feature we talked about earlier:

git branch dark-mode-feature

Run git branch again and you'll see both branches listed, but notice the asterisk is still next to main. Creating a branch doesn't automatically move you onto it. You have to switch:

git switch dark-mode-feature

Warning: You might see older tutorials use git checkout dark-mode-feature instead. That still works, but checkout is an old command that does too many different things at once (switching branches, restoring files, and more), which is exactly what confuses beginners. git switch was introduced specifically to make branch switching its own clear command. Use switch if you can.

Or, if you want to create and switch in one move (which is what you'll do 90% of the time), use:

git switch -c dark-mode-feature

The -c flag means "create." Now go ahead, make some changes to a file, and commit them like normal:

git add .
git commit -m "Add dark mode toggle button"

Here's the part that trips people up the first time: switch back to main with git switch main, and open that file again. Your dark mode changes are gone. Not deleted, just not there on this branch. Switch back to dark-mode-feature and they reappear.

That "vanishing and reappearing" moment is honestly when branching finally clicks for most people. You're not editing one timeline anymore. You're hopping between separate ones, and Git is keeping each one perfectly intact.

A Live Demo: How Branches Relate to Each Other

Reading about commits and timelines is one thing, seeing it move is another. Here's a simple interactive demo. Click the buttons below to simulate switching between two branches and watch how the "working file" content changes instantly, exactly like it does in your actual terminal.

Current branch: main

Welcome

Standard light theme. This is what main branch looks like.

That's the whole idea in a nutshell. Same project, same file, completely different content depending on which branch is currently checked out. Nothing is duplicated on disk, Git just shows you the version tied to whichever branch you're standing on.

Now Comes the Fun Part: Merging Your Work Back

Once your dark mode feature is done and tested, you want it back in main so it becomes part of the official project. Switch to the branch you want to merge into first:

git switch main
git merge dark-mode-feature

If nobody else touched the same lines of code while you were working, Git merges everything automatically and you'll see a message like:

Fast-forward
 style.css | 12 ++++++++++++
 1 file changed, 12 insertions(+)

"Fast-forward" just means main didn't have any new commits of its own since you branched off, so Git simply moved main's pointer forward to include your changes. Clean and simple.

Success: Once merged, you can safely delete the feature branch with git branch -d dark-mode-feature. Deleting a branch doesn't delete your commits, they're already living permanently inside main now. You're just cleaning up the label.

What If Two Branches Changed the Same Lines?

This is the scenario people fear most, the dreaded "merge conflict." But it's honestly less scary than its reputation suggests once you've done it once or twice.

Say both main and your feature branch modified the same line in style.css. When you run git merge, Git can't decide which version is correct, so it stops and asks you. Opening the file, you'll see something like this:

<<<<<<< HEAD
background-color: white;
=======
background-color: #1a1a1a;
>>>>>>> dark-mode-feature

Everything between <<<<<<< HEAD and ======= is what's currently on your branch (main, in this case). Everything between ======= and the branch name is what's coming in from the other branch. You just edit the file to keep whichever version makes sense (or blend both), delete those marker lines, then save and commit:

git add style.css
git commit -m "Resolve merge conflict in style.css"

That's it. No magic, no special conflict-resolution command. It's literally just editing a text file to remove ambiguity, then committing like normal.

A Naming Convention That'll Save You Real Headaches

Here's something that isn't in most beginner guides, but genuinely matters once you're working on real projects, especially in a team. Vague branch names like test, new-stuff, or fix become useless the moment you have more than three or four branches open. Nobody, including future you, can tell what they contain without opening each one.

A pattern that works well and that we use across projects at BytebaseX looks like this:

Prefix	Use case	Example
feature/	New functionality	feature/dark-mode
fix/	Bug fixes	fix/login-crash
chore/	Maintenance, no user-facing change	chore/update-dependencies
hotfix/	Urgent production fix	hotfix/payment-bug

This small habit means anyone (including you, six months from now) can glance at a branch list and immediately understand what's going on, without opening a single file.

One Command Most Beginners Never Learn, But Should

Here's the "something new" part I promised. Most beginner guides stop at branch, switch, and merge. But there's a command that will genuinely change how you work once you know it exists: git switch -.

git switch -

Just like cd - in your terminal takes you back to the previous directory, git switch - takes you back to whichever branch you were on before your last switch. If you're bouncing between main and a feature branch constantly (which happens a lot when reviewing code or checking something quickly), this single command saves you from typing the full branch name over and over.

It's a small thing, but small things like this are exactly what separate someone who "knows Git commands" from someone who actually works efficiently with Git day to day.

Common Mistakes Beginners Make With Branching

Let's cover a few things that trip people up, based on questions we hear a lot.

Forgetting Which Branch You're On

You make changes, commit them, and then realize you were on main the whole time instead of your feature branch. This happens to everyone. The fix depends on whether you've already committed:

If you haven't committed yet, you can just create the branch now and your uncommitted changes will move with you:

git switch -c feature/oops-forgot-branch

If you already committed, you can move that last commit to a new branch:

git branch feature/oops-forgot-branch
git reset --hard HEAD~1

Error to avoid: Only use git reset --hard when you're absolutely sure what you're discarding. It rewrites your current branch to an earlier point and any changes not saved elsewhere are gone for good. Double check with git log first if you're unsure.

Branching Off an Outdated Main

If your main branch has moved forward since you last pulled, but you branch off your old local copy, you'll end up merging in stale code later and creating unnecessary conflicts. Before starting new work, it's worth running:

git switch main
git pull
git switch -c feature/new-thing

Three extra seconds now saves you a genuinely annoying conflict cleanup later.

Quick Reference: Commands Covered in This Guide

• git branch — list branches, or create one if you give it a name
• git switch branch-name — move to an existing branch
• git switch -c branch-name — create a branch and switch to it in one step
• git switch - — jump back to your previous branch
• git merge branch-name — merge the named branch into your current branch
• git branch -d branch-name — delete a branch that's already merged

Frequently Asked Question

Do I need to create a branch for every tiny change?

Not necessarily. For a solo weekend project, working directly on main is fine. Branching earns its value once you're juggling multiple features, working with a team, or need to keep your main code always deployable. As a rule of thumb, if a change takes more than a single commit or touches something risky, branch it.

What's the difference between "main" and "master"?

No functional difference. They're just names. Git used to default to master as the primary branch name, and most tools and hosting platforms now default to main instead. You can rename yours anytime with git branch -m master main if you're working with an older project.

Can I switch branches if I have uncommitted changes?

Sometimes. Git will let you switch if the changes don't conflict with anything on the target branch. If they do, Git will stop you and suggest either committing first or using git stash, which temporarily shelves your changes so you can bring them back later with git stash pop.

What happens to a branch after I merge and delete it?

Nothing bad. Your commits are already merged into the target branch permanently, so deleting the branch just removes the label pointing to them. The commit history stays intact and visible in git log.

Is it bad to have a lot of branches open at once?

Not inherently, but it gets messy fast without a naming convention (see the table above) and occasional cleanup. A good habit is deleting branches right after they're merged, so your branch list only shows work that's actually in progress.

Should I use a GUI tool instead of the terminal for branching?

Either works fine, and tools like GitHub Desktop or the Git panel in VS Code can make branching feel more visual. That said, learning the terminal commands first genuinely helps, because GUI tools eventually hit edge cases (like conflicts) where understanding what's happening underneath makes troubleshooting much faster.

Wrapping This Up

And that's branching, minus the confusing jargon and the "just trust me" explanations that leave you more lost than before. You now know why branches exist, how to create and switch between them, how merging actually works under the hood, and even a couple of habits that most tutorials skip entirely.

Here's the honest truth from our side at BytebaseX: nobody memorizes all of Git's commands, and you don't need to. What matters is understanding the mental model, separate timelines you can hop between safely, and the rest becomes muscle memory the more you use it. Go create a throwaway branch right now and mess around with it. That's genuinely the fastest way this sticks.

If this helped clear things up, stick around. We're building out more of these practical, no-fluff guides for developers who just want things explained properly. See you in the next one.