How to Make a New Branch in Git: A Complete Guide

Creating a new branch in Git is one of the most common tasks in version control — and one of the most powerful. Whether you're fixing a bug, building a feature, or experimenting with code, branching lets you work in isolation without touching the main codebase. Here's exactly how it works and what you need to know to use it confidently.

What Is a Git Branch?

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

The default branch in most repositories is called main (or master in older projects). Every other branch you create lives independently until you decide to merge it back.

This isolation is the core value of branching. Changes made on one branch don't affect any other branch until you explicitly merge or rebase them.

The Basic Command: git branch and git checkout

The most straightforward way to create a new branch uses the git branch command:

git branch feature/my-new-feature 

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

To switch to the new branch:

git checkout feature/my-new-feature 

Or combine both steps into one with the -b flag:

git checkout -b feature/my-new-feature 

This is the classic approach and still widely used across teams and tutorials.

The Modern Alternative: git switch

Git 2.23 introduced git switch as a cleaner, more explicit command for changing branches:

git switch -c feature/my-new-feature 

The -c flag means create. It's functionally equivalent to git checkout -b but is considered more readable because git checkout historically handled too many different tasks (switching branches, restoring files, etc.).

If you're on a newer Git installation, git switch is generally the recommended approach for branch operations specifically.

Creating a Branch From a Specific Point

By default, a new branch starts from wherever HEAD currently points — usually your latest commit on the current branch. But you can also branch from:

A specific commit:

git checkout -b hotfix/bug-123 a1b2c3d 

Another branch:

git checkout -b feature/new-ui origin/develop 

A tag:

git checkout -b release/v2.0 v2.0-rc1 

This flexibility matters when you need to patch an older release, start a feature from a shared integration branch, or reproduce a bug from a known state.

Pushing a New Branch to a Remote

Creating a branch locally doesn't automatically share it with your team. To push it to a remote (like GitHub, GitLab, or Bitbucket):

git push -u origin feature/my-new-feature 

The -u flag sets the upstream tracking relationship, meaning future git push and git pull commands on that branch will automatically know which remote branch to sync with. Without -u, you'd need to specify the remote and branch name every time.

Branch Naming: Conventions That Matter

Git itself has minimal restrictions on branch names, but teams typically adopt conventions that make branches easier to manage at scale:

Consistent naming makes branch lists scannable and integrates cleanly with issue trackers and CI/CD pipelines that parse branch names to trigger workflows.

Viewing Your Branches 🌿

To see all local branches:

git branch 

To see local and remote branches:

git branch -a 

The branch with an asterisk (*) is your currently active branch. Tracking information (which remote branch it follows) shows up with git branch -vv.

Key Variables That Affect Your Branching Workflow

Understanding the commands is the easy part. How branching fits into your workflow depends on several factors:

Team size and structure — Solo developers can be flexible with branch naming and lifecycle. Teams of 10+ usually need stricter conventions, protected branches, and merge/PR policies.

Git workflow model — Whether your team uses Git Flow (long-lived feature, develop, and release branches), trunk-based development (short-lived branches merged frequently to main), or GitHub Flow (feature branches + pull requests) changes how and when you create branches.

Repository hosting platform — GitHub, GitLab, and Bitbucket each have slightly different behavior for branch protection rules, default branch settings, and how they display or delete remote branches after merges.

CI/CD integration — Many pipelines trigger automated tests or deployments based on branch names or patterns. How you name and structure branches may need to align with those rules.

Git version — git switch requires Git 2.23+. If you're working in environments with older Git installs (some servers, legacy systems), git checkout -b remains the safe universal option.

What Happens After You're Done With a Branch

Branches aren't meant to live forever. Once work is merged, the branch is typically deleted:

git branch -d feature/my-new-feature # delete locally git push origin --delete feature/my-new-feature # delete remotely 

Using -d (lowercase) only deletes the branch if it's already been merged. Using -D forces deletion regardless — useful for abandoned work, but irreversible without knowing the commit hash.

The Part Only Your Setup Can Answer

The commands here are consistent across Git environments — but the right branching strategy, naming conventions, lifecycle rules, and remote workflow depend entirely on how your project is structured, who's collaborating with you, and what tooling sits on top of your repository. A solo developer on a personal project operates very differently from an engineer on a team using protected branches, required code reviews, and automated deployment pipelines.

The mechanics are learnable in an afternoon. How they map to your specific situation is what takes more thought. 🔧