How to Create a Branch in Git: A Complete Guide

Git branches are one of the most powerful features in version control — and one of the most misunderstood by developers just getting started. Whether you're working solo or collaborating with a team, knowing how to create and manage branches effectively changes how you work with code.

What Is a Git Branch?

A Git branch is essentially a lightweight, movable pointer to a specific commit in your repository's history. When you create a branch, you're not duplicating your entire codebase — Git is simply creating a new reference point that lets you diverge from the main line of development.

The default branch in most repositories is called main (or master in older setups). Every new branch you create starts as a copy of wherever you are in the commit history at that moment, then evolves independently as you make changes.

This matters because branching lets you:

• Work on a new feature without touching stable code
• Fix bugs in isolation
• Experiment without consequences
• Collaborate without overwriting each other's work

How to Create a Branch in Git 🌿

The Basic Command

The simplest way to create a new branch is:

git branch branch-name 

This creates the branch but does not switch to it. You're still working on your current branch.

To switch to the newly created branch:

git checkout branch-name 

The Shortcut: Create and Switch in One Step

Most developers use this combined command instead:

git checkout -b branch-name 

The -b flag tells Git to create the branch and immediately check it out. This is the most common pattern you'll see in day-to-day work.

If you're using Git 2.23 or later, the newer switch command is the preferred alternative:

git switch -c branch-name 

The -c stands for "create." It does the same thing as checkout -b but is considered more readable and explicit.

Creating a Branch from a Specific Commit or Branch

By default, your new branch starts from HEAD — wherever you currently are. But you can also branch off a specific point:

git checkout -b branch-name existing-branch git checkout -b branch-name commit-hash 

This is useful when you need to create a hotfix from a previous release tag, or when you want a feature branch based on a shared development branch rather than main.

Naming Your Branches

Branch naming conventions aren't enforced by Git itself, but they matter a lot for team workflows. Common patterns include:

Most teams agree on one system and stick with it. What matters is that the branch name tells someone — at a glance — what the branch is for.

Pushing a Branch to a Remote Repository

Creating a branch locally doesn't automatically make it available to others. To push it to a remote (like GitHub or GitLab):

git push -u origin branch-name 

The -u flag sets the upstream tracking relationship, which means future git push and git pull commands on that branch will automatically know where to sync. After the first push with -u, you can just type git push from that branch going forward.

Viewing and Managing Branches

A few commands that are useful once you're working across multiple branches:

git branch # List all local branches git branch -r # List remote branches git branch -a # List all branches (local + remote) git branch -d branch-name # Delete a branch (safe — won't delete unmerged work) git branch -D branch-name # Force delete (even if unmerged) 

The current branch is always shown with an asterisk (*) in the git branch output.

Where Branching Strategy Starts to Vary ⚙️

The mechanics of creating a branch are consistent — the commands above work everywhere. But how you use branches depends heavily on your context.

Team size changes everything. A solo developer might work directly on main for small projects and only branch for experiments. A team of ten might require every change to go through a feature branch, a code review, and a merge request — with branch names tied to project management tickets.

Workflow model also shapes your branching habits. Git Flow uses long-lived branches like develop, release, and hotfix alongside main. GitHub Flow keeps things simpler — short-lived feature branches that merge directly into main. Trunk-based development takes it further, with very short-lived branches or even direct commits to the main branch paired with feature flags.

Project type plays a role too. A library with public releases needs careful versioning across branches. An internal tool with continuous deployment might rarely keep a branch alive for more than a day.

Technical skill level on the team affects how complex a branching strategy can practically be. Branching models that look clean on a diagram can create real friction if the team isn't comfortable rebasing, resolving merge conflicts, or handling diverged histories.

The gap between knowing how to create a branch and knowing which branching approach fits your project is exactly where your own situation — your team, your release cadence, your tooling — becomes the deciding factor.