Branching Basics – What, Why, and How to Use Them Without Screwing Up
A beginner-friendly Git guide that won’t melt your brain
Note:
This guide is written for solo developers working independently with Git.
If you’re working in a team or contributing to shared repositories, some practices may differ.
A follow-up guide on team workflows, conflict handling, and collaboration best practices is coming soon.
Why Branching Exists
If you’ve ever made a change and instantly regretted it — congratulations, you’re why Git branches exist.
Branches let you try things without breaking the rest of your code. You can test features, fix bugs, or explore wild ideas while keeping your main codebase safe and untouched. Think of it like saving your game before doing something reckless.
What a Branch Is (No Jargon)
A branch is a separate copy of your project that you can edit without affecting the original.
It’s like duplicating a document so you can mess with it guilt-free. Once you’re happy, you can merge your changes back into the main file.
You can have multiple branches, each with its own purpose — new features, bug fixes, experiments. You’re not locked into one track.
How to Create a Branch
Option 1: GitHub Desktop
- Open your repo in GitHub Desktop
- Click Current Branch > New Branch
- Give it a short, descriptive name like fix-login-error or add-dark-mode
- Click Create Branch
You’re now working in that new branch. All changes go there until you switch back.
Option 2: Git CLI (Command Line)
git checkout -b my-new-branch
That creates and switches to my-new-branch in one shot.
To switch between branches:
git checkout main
Or in GitHub Desktop: use the dropdown to switch context.
When You’d Use a Branch
- Fixing a bug without touching the stable code
- Adding a feature without breaking what’s already working
- Collaborating with others without constant merge conflicts
- Trying something experimental that might not stick
You can branch off anything: main, develop, even other branches.
Common Beginner Mistakes
Making changes on the wrong branch
Forgetting to switch before editing
Using vague names like test1 or new-branch
Never deleting old branches that are already merged
Keep it clean, or you’ll regret it later.
Best Practices
- Keep branch names short, lowercase, and dashed (e.g., fix-header-link)
- Only work on one thing per branch
- Merge branches once tested and reviewed
- Delete local and remote branches after merging to avoid clutter
- Always start from an updated base (e.g., main) before branching
What’s Next
In the next post, we’ll walk through Pull Requests: what they are, how to create one, and how they fit into your Git workflow.
Until then, branch out — just don’t forget to come back.
Got Questions or Want a Deeper Dive?
Not sure how to name your branches? Confused about local vs remote cleanup?
If there’s a part of branching you’d like explained more clearly — or with real examples — let me know in the replies.
I read everything. If it’s helpful to you, it’s probably worth a follow-up post.