Beginner's guide to Git branching

If you clicked on this, chances are you've typed git commit -m "fixed stuff" more than once, pushed straight to main, and quietly hoped nothing broke. That's an extremely common way to start out with Git, and it usually keeps working right up until two things need to happen at once.

This is a plain walkthrough of Git branching for people who are tired of tutorials that assume you already know what a "detached HEAD" is. (For what it's worth, that message still makes plenty of experienced developers pause for a second.)

By the end, you'll understand not just the commands, but why branching exists in the first place, with a mental model that's built to stick rather than fade the moment you close the tab.

The Problem Branching Actually Solves

Let's start with the actual problem, because jumping straight to git branch without explaining why you'd bother is part of why branching feels confusing at first.

Imagine you're working on a small app. It works, it's live, and now you want to add a dark mode toggle. Halfway through, you realize it's a three-day job, 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. The dark mode code is half-written and broken, so you can't cleanly pause and fix the bug, 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 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 doesn't pan out, you 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?

Fair question, and it's a common instinct before learning Git. You end up with folders like project-final, project-final-v2, project-final-ACTUAL-final. It holds up for a day or two, then turns into a nightmare because it's hard to track what changed where.

Branches solve this because they're lightweight and live inside the same project. Nothing is being duplicated; 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 create a new branch for that dark mode feature:

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 older 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, to create and switch in one move, which covers most real-world cases, use:

git switch -c dark-mode-feature

The -c flag means "create." Now 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 usually when branching finally clicks. You're not editing one timeline anymore. You're hopping between separate ones, and Git keeps each one perfectly intact. It's also worth noticing what didn't happen: nothing was copied, deleted, or re-downloaded. Git just changed which version of the file your folder is currently pointing to, which is the same trick that makes switching fast no matter how large the project is.

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." It's less alarming than its reputation suggests once you've worked through one or two.

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 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 special conflict-resolution command. It's literally editing a text file to remove ambiguity, then committing like normal.

One thing worth knowing early: a merge conflict is not Git telling you something went wrong. It's Git refusing to guess on your behalf when two people had different ideas about the same line. That's arguably the safer outcome, since the alternative would be silently picking one version and hoping it was the right one.

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 with other people. 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 prefix-based pattern is common in team projects and tends to hold up well as a project grows:

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. It also pays off the moment a second person joins the project: a shared naming pattern is often the difference between a branch list that explains itself and one that needs a group chat to decode.

One Command Most Beginners Never Learn, But Should

Most beginner guides stop at branch, switch, and merge. But there's a command that changes 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 moves through Git quickly without thinking about it.

Common Mistakes Beginners Make With Branching

A few things reliably trip people up early on. Here's what's going on and how to recover.

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 nearly everyone at some point. 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 can save an 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 Questions

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.

The Part That Doesn't Show Up in the Command List

Every command above is easy to look up again later. What's harder to look up is the instinct for when to reach for them, and that instinct only comes from one place: making a branch before you're sure you need one.

Here's a way to think about it that might not show up elsewhere. A branch costs you almost nothing to create and almost nothing to throw away. That asymmetry is the whole point. Most tools in software ask you to commit before you know if an idea is good. Branching is one of the rare ones that lets you find out first, for free, and only pay for it once you're sure.

So the fastest way to make this stick isn't rereading the commands. It's opening a terminal, running git switch -c whatever-you-want on a real project, and doing something you're not sure will work. If it works, merge it. If it doesn't, delete it. Either way, you'll understand branching better in the next five minutes than in the last five sections, because you'll have felt the part that made it worth inventing: the freedom to be wrong without it costing you anything.

Adapted and revised guide on Git branching for beginners.