What is Git Branch? How to Use It?

When you initialize version control with git init, Git automatically creates a default branch — usually called main, or master in some projects. Active development typically doesn't happen directly on main, especially in team environments. That's because main holds the stable, working version of the project. Developers create new branches off of it, work independently, and merge their changes back when ready.

Think of it like parallel universes in a sci-fi film. You create a copy of the current project and work on that copy. Changes you make there don't affect the original until you explicitly merge them.

Why Use Branches?

There's no single answer. The reasons generally fall into a few categories: safe development, parallel collaboration, and a clean project history.

One of the biggest advantages of version control systems like Git and SVN is that they make it easier for multiple developers to work on the same project. Git's branch model takes this even further — every developer can maintain multiple independent copies of the project on their own machine, all based on the latest state of the codebase.

• Safe development: You can branch off the current stable version and experiment with new features or alternative approaches. If something breaks or remains unfinished, it doesn't matter — those changes are isolated to that branch. As long as you don't run git merge, the main branch stays completely untouched.
• Parallel collaboration: Everyone on the team can work on different things simultaneously without waiting on each other. They each work on their own branch and merge when done. This isn't exclusive to teams either — even solo developers benefit from keeping separate concerns on separate branches.

  Multiple people can work on different branches at the same time without interfering with each other.

• Clean history: Each feature is developed in its own branch, which enables proper code review before merging. When you run git log, it becomes much easier to trace what changed, when, and why.

Without branches, everyone would be working directly on the main codebase — risking breakage, creating bottlenecks, and turning the project history into a mess.

How to Use Git Branch

Branches typically come into play when you're building a new feature or want to make changes without risking the existing code. The most common workflow is to branch off main, do your work, and merge back when it's done.

Say you have a working project and you need to add a new feature — but if you leave it half-finished, things might break. Opening a branch is the right call here. You write the new code there, and once it's ready, you merge it back into the main codebase. This keeps the development process controlled and reduces the risk of introducing bugs into production.

A Simple Example

# create a new branch and switch to it
git switch -c feature/login

# do your work
git add .
git commit -m "add login feature"

# go back to main
git switch main

# merge your changes into main
git merge feature/login

Instead of working directly on main, you isolate your changes in a separate branch. This way, main stays stable throughout. For more on creating commits, check out the git commit guide.

In real-world projects, almost all development follows this pattern: a separate branch for each feature, merged back into main when the work is complete.

Basic Branch Commands

• git branch feature-login: Creates a new branch.
• git switch feature-login: Switches to an existing branch.
• git switch -c feature-login: Creates a new branch and switches to it in one step.
• git branch -d feature-login: Deletes a branch that has already been merged.
• git branch -D feature-login: Force-deletes a branch regardless of merge status.
• git branch -m new-name: Renames the current branch.
• git switch main: Returns to the main branch.
• git switch -: Quickly switches back to the previous branch.
• git branch: Lists all local branches. The active one is marked with *.
• git status / git status -sb: These belong to the status command, but both show which branch you're currently on.

Branch Naming Conventions

There are no hard technical rules, but the developer community has settled on some widely accepted conventions. Use / for hierarchy and - to separate words. Spaces and uppercase letters are discouraged. In solo projects you don't have to be this strict, but building the habit early is worth it.

How Does Git Branch Work?

Every commit in Git has a unique ID — a SHA hash. A branch is simply a small reference file that points to one of those commits.

.git/refs/heads/main          # contains: abc123
.git/refs/heads/new-feature   # contains: def456

When you create a branch, Git is essentially just writing a new file to its internal structure. That's why branches are so fast and lightweight — each one is nothing more than a file holding a single commit hash.

A branch is just a small text file containing a 40-character hash.

Git Switch vs Git Checkout

Both commands work for switching branches. So why do two commands exist for the same job? In Git 2.23 (2019), the responsibilities of git checkout were split into two focused commands: git switch for changing branches, and git restore for restoring files. Both are still supported.

git checkout feature/login   # old way
git switch feature/login     # new way, same result

git checkout still works, but it's no longer the recommended approach.

Common Mistakes

• Committing directly to main is probably the most common mistake — forgetting to create a branch and pushing changes straight to the main branch. It might not matter much on small solo projects, but it's a habit worth building early.
• Not deleting merged branches. Once a branch has served its purpose and been merged, leaving it around just adds clutter over time.
• Waiting too long to merge. The longer a branch lives, the further it drifts from main — and the higher the chance of merge conflicts.
• Committing to the wrong branch. You forgot to switch and accidentally committed to main or some other branch. Running git status before committing helps you catch this — it always shows which branch you're on.
• Using vague branch names is a bad habit. Names like test or try don't communicate anything. You'll forget what they were for, and so will your teammates.
• Trying to delete an unmerged branch with -d: git branch -d won't delete a branch that hasn't been merged yet. In moments like this, you'll be glad Git has your back.