How to Create a New Branch in Git: From Current, Another, Commit, Tag & Remote

|

Learn how to create a new branch in Git step-by-step. Discover commands to create a branch from the current branch, another branch, specific commit, tag, or master—and how to push it to remote. Perfect for beginners and advanced developers using GitHub or any Git workflow.

Git
~12 min read
Best Practices
How to Create a New Branch in Git

What Does “Create a Branch in Git” Mean?

In Git, a branch is a lightweight, movable pointer to a commit. When you create a branch, you’re not duplicating the entire repository — you’re simply telling Git to track a new line of development starting from a specific point in history. The working files remain identical until you start making changes on that branch.

Understanding the git command to create new branch workflows is one of the most foundational skills in modern software development. Whether you’re adding a feature, fixing a bug, or experimenting with a new idea, branching lets you do it safely in isolation.

Why branching is important in Git workflows

The entire Git workflow — GitFlow, GitHub Flow, trunk-based development — is built around the idea that the main branch should always be stable. Every change lives on its own branch until it’s reviewed, tested, and ready to merge.

  • Isolates work so failures don’t affect the main codebase
  • Enables parallel development across multiple features or team members
  • Makes code review (pull requests) a natural part of the workflow
  • Provides a clean history that’s easy to understand and revert
  • Powers CI/CD pipelines — each branch can trigger its own test suite

When you should create a new branch

Create a new branch whenever you’re starting work that you don’t want to land immediately in the main codebase. Practically, that means:

Common Branching Triggers

Feature work: Any new user-facing functionality — create a feature/ branch before writing the first line of code.
Bug fixes: Even small fixes deserve a branch. It makes the PR reviewable and the history meaningful.
Hotfixes: Branch off the production tag or release branch, not main, so you include only the fix.
Experiments: Prototypes, spikes, and proof-of-concept work — branch freely and delete when done.
Releases: Many teams cut a release/1.4.0 branch from main for final stabilization before shipping.

Git Command to Create a New Branch

The core git command to create new branch is git branch. It’s simple, low-level, and does exactly one thing: creates a branch pointer. It does not switch you to the new branch.

Basic command: git branch <branch-name>

Bash – Terminal
# Create a new branch called "feature/login"
git branch feature/login

# List all local branches to verify it was created
git branch

Output

feature/login * main

Notice the * still points to main. You created the branch but didn’t switch to it.

Difference between creating and switching branches

This is one of the most common points of confusion for new Git users. The git branch command only creates. You need a separate step to switch:

GoalCommandSwitches?
Create onlygit branch feature/xNo
Create + switch (classic)git checkout -b feature/x✔ Yes
Create + switch (modern)git switch -c feature/x✔ Yes
Switch to existinggit switch feature/x✔ Yes

Git Create Branch and Checkout (Switch)

In day-to-day work, you almost always want to create the branch and immediately start working on it. Git gives you two shorthand commands for this.

Using git checkout -b

The classic way to git create branch and checkout in a single step. The -b flag tells checkout to create the branch if it doesn’t exist, then switch to it.

Create and switch in one step (classic)
# Create "feature/user-auth" and switch to it immediately
git checkout -b feature/user-auth

Output

Switched to a new branch ‘feature/user-auth’

Using git switch -c (modern approach)

Git 2.23 introduced git switch to separate the concerns of git checkout, which was overloaded with too many responsibilities. The -c flag means “create.” This is the recommended modern approach.

Create and switch (modern — Git 2.23+)
# Identical result to checkout -b, but clearer intent
git switch -c feature/user-auth

# Verify you're on the right branch
git branch --show-current

Output

Switched to a new branch ‘feature/user-auth’ feature/user-auth

Pro Tip

Both checkout -b and switch -c produce identical results. Use switch -c in new projects and scripts — it’s more readable and less error-prone. Use checkout -b when working on older Git installs (pre-2.23) or following legacy docs.

Git Create New Branch from Current Branch

When you run git branch <name> or git switch -c <name> without specifying a starting point, Git automatically uses your current HEAD commit as the base. This means the new branch starts as an exact copy of wherever you are right now.

Default behavior explained

This is the most common branching pattern. You’re on main, it’s up to date, and you want to git create a new branch from current position to start feature work:

Branching from current HEAD (implicit)
# You're on main — these two are equivalent:
git switch -c feature/dark-mode
git switch -c feature/dark-mode main  # explicit is also fine

# Inspect the starting point
git log --oneline -3

Output

Switched to a new branch ‘feature/dark-mode’ a3f9d2e Add user settings page 7bc1099 Refactor auth middleware d8a4451 Initial commit

Example workflow

Real-World Scenario: Feature Branch from Main

You start every Monday by updating main, then branch off for the week’s work:
Monday morning workflow
# 1. Make sure you're on main
git switch main

# 2. Pull the latest changes
git pull origin main

# 3. Create your feature branch from the freshest main
git switch -c feature/payment-gateway

# 4. Start coding — your work is now isolated

Git Create Branch from Another Branch

Sometimes you need to git create branch from another branch — not the one you’re currently on. For example, you may be on feature/dashboard but want a sub-branch off develop, or you need to hotfix off a release branch without switching your working context first.

Step-by-step example

Branch from a different branch without switching first
# Syntax: git branch <new-branch> <source-branch>

# You're currently on "feature/dashboard"
git branch --show-current
# feature/dashboard

# Create "hotfix/checkout-bug" from "release/2.3", staying where you are
git branch hotfix/checkout-bug release/2.3

# Now switch to it when ready
git switch hotfix/checkout-bug

# Or do it all in one step with switch -c:
git switch -c hotfix/checkout-bug release/2.3

Common mistakes to avoid

Watch Out

Branching from a stale local copy. If release/2.3 hasn’t been fetched recently, your new branch won’t include the latest remote commits. Always run git fetch origin before branching from a non-main branch.
Safe pattern: fetch first, then branch
# Fetch everything from remote without merging
git fetch origin

# Branch from the remote-tracking reference to guarantee freshness
git switch -c feature/new-report origin/develop

Git Create New Branch from Master (or Main)

Branching from the primary integration branch is the most common operation in any Git workflow. Whether you’re doing git create new branch from master or from main, the commands are identical — only the branch name changes.

Why “main” vs “master” matters

GitHub changed the default branch name from master to main in October 2020. GitLab followed. New repositories default to main; older ones may still use master. Always check which name your project uses before scripting:

Check your default branch name
# Option 1: List branches and look for the asterisk
git branch -a

# Option 2: Query the remote's HEAD directly
git remote show origin | grep "HEAD branch"

Output

HEAD branch: main
Create branch from main / master
# If your default branch is "main":
git switch main
git pull origin main
git switch -c feature/api-refactor

# If your default branch is still "master":
git switch master
git pull origin master
git switch -c feature/api-refactor

Keeping your branch up to date

Once you’ve been working on your branch for a few days, main may have moved ahead. Keep your branch in sync by rebasing (preferred for a clean history) or merging:

Syncing feature branch with main
# Option A: Rebase (cleaner history)
git fetch origin
git rebase origin/main

# Option B: Merge (preserves branch topology)
git merge origin/main

Git Create Branch from Specific Commit

Branching from a specific commit is invaluable for hotfixes, bisect investigations, and reconstructing historical state. To git create branch from specific commit, you need the commit’s SHA hash — a 40-character (or abbreviated 7-character) identifier.

Finding the commit hash with git log

Find the commit you want to branch from
# Pretty one-line log — easy to scan
git log --oneline --graph -10

# Search commits by message keyword
git log --oneline --grep="payment"

# Find commits that changed a specific file
git log --oneline -- src/checkout.js

Output — pick your target SHA

a3f9d2e Add user settings page 7bc1099 Refactor auth middleware 4de2f11 Fix payment callback URL ← target d8a4451 Add checkout flow c3b8892 Initial commit

Creating branch from commit

Branch off a specific commit SHA
# Use the full or abbreviated SHA as the start point
git switch -c hotfix/payment-url 4de2f11

# Verify the branch starts at the right commit
git log --oneline -3

Output

Switched to a new branch ‘hotfix/payment-url’ 4de2f11 Fix payment callback URL d8a4451 Add checkout flow c3b8892 Initial commit

Note

Git accepts abbreviated SHAs (7 characters is usually enough for uniqueness) as well as full 40-character hashes. If Git complains about ambiguity, use more characters or the full hash.

Git Create Branch from Tag

Tags in Git mark specific points in history — typically release versions like v2.1.0. When you need to hotfix a shipped version or reproduce a bug that was reported against a specific release, you’ll want to git create branch from tag.

When to branch from a tag

Real-World Scenario: Production Hotfix

Your team shipped v3.2.0 last week. A critical bug is reported in production. Meanwhile, main has moved on with unrelated work. You need to patch v3.2.0 specifically — so you branch from the tag, not from main.

Example command

List tags, then branch from one
# See all tags (sorted by version)
git tag --sort=-version:refname | head -5

# Fetch tags from remote if needed
git fetch origin --tags

# Create a hotfix branch from tag v3.2.0
git switch -c hotfix/v3.2.1 v3.2.0

# Verify: you should be at the tagged commit
git log --oneline -2

Output

Switched to a new branch ‘hotfix/v3.2.1’ f91a3bb Release v3.2.0 (tag: v3.2.0) e22d7ac Fix cart total rounding error

Lightweight vs Annotated Tags

Both types work identically as a branch starting point. Annotated tags (created with git tag -a) carry extra metadata (tagger, date, message) but the branching command is the same either way.

Git Create Branch and Push to Remote

A branch created locally exists only on your machine until you push it. To git create branch and push to remote — making it visible to your teammates and triggering CI — you need one extra step.

First push with upstream (-u)

The -u flag (short for --set-upstream) links your local branch to the remote branch. After the first push, you can use plain git push and git pull without specifying the remote or branch name.

Create locally, then push and track remote
# Create branch locally
git switch -c feature/notifications

# Make a commit (remote push requires at least one commit or -u works anyway)
git add .
git commit -m "feat: add notification badge component"

# Push and set upstream tracking in one command
git push -u origin feature/notifications

# All future pushes on this branch can now just be:
git push

Output

Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 8 threads To github.com:myorg/myrepo.git * [new branch] feature/notifications -> feature/notifications Branch ‘feature/notifications’ set up to track remote branch ‘feature/notifications’ from ‘origin’.

Verifying the branch on remote

Confirm the remote branch exists
# List remote branches
git branch -r

# Or list all (local + remote)
git branch -a

# Check tracking info
git branch -vv

git branch -vv output

* feature/notifications a3f9d2e [origin/feature/notifications] feat: add notification badge component main d8a4451 [origin/main] Merge PR #42: user settings

GitHub: How to Create a New Branch

If you prefer a visual interface, GitHub makes it easy to create branches directly in the browser — no terminal required. Here’s exactly how to do it when wondering about github how to create new branch.

Creating a branch in the GitHub UI

  1. Navigate to your repository on GitHub.
  2. Click the branch selector dropdown — it shows the current branch name (usually main) near the top-left of the file list.
  3. In the search box that appears, type your new branch name (e.g., feature/dark-mode).
  4. If no existing branch matches, GitHub shows a “Create branch: feature/dark-mode from main” option — click it.
  5. The page refreshes and you’re now viewing the new branch. GitHub automatically bases it on whatever branch was selected when you opened the dropdown.

GitHub Shortcut

On any repository page, press t to open the file finder, or press / to focus the search bar. On the Code tab, the branch switcher is keyboard-accessible — type to filter existing branches or create a new one.

CLI vs GitHub UI comparison

AspectTerminal (CLI)GitHub UI
Speed (experienced user)✔ FasterSlower (navigation)
Custom starting point Any commit, tag, or branchCurrent branch only
Visibility for new usersLearning curve✔ Visual & intuitive
Scripting & automation✔ ScriptableNot scriptable
Offline use✔ Works offlineRequires internet
Draft PR on creationSeparate step✔ Prompt shown immediately

For most day-to-day development, the CLI is faster and more powerful. The GitHub UI shines for quick branch creation without switching context, especially for non-engineers (designers, PMs) who need to create feature branches.


Common Errors When Creating Git Branches

Even experienced developers hit these snags. Here’s how to diagnose and fix the most common ones.

Branch already exists

Error: branch already exists
git switch -c feature/login
fatal: A branch named 'feature/login' already exists.

Fix

Either switch to the existing branch with git switch feature/login, choose a different name, or (if you’re sure) delete the old branch first with git branch -d feature/login and recreate it.

Detached HEAD issues

A “detached HEAD” happens when you check out a commit, tag, or remote branch directly instead of a local branch pointer. Commits made in this state are not attached to any branch and can be lost.

Recognizing and fixing detached HEAD
# You might see this after checking out a commit directly
HEAD detached at 4de2f11

# Fix 1: Create a branch right now to "save" your position
git switch -c recovery/detached-work

# Fix 2: Go back to main and abandon detached state
git switch main

Wrong base branch

You created a branch off develop when you meant to branch from main. The branch contains extra commits you didn’t want.

Rebase a branch onto the correct base
# Rebase "feature/x" so it branches from "main" instead of "develop"
git rebase --onto main develop feature/x

# Syntax: --onto <new-base> <old-base> <branch>

Before Rebasing a Pushed Branch

If the branch has already been pushed and others might have pulled it, rebase will rewrite history. Coordinate with your team, or use git merge instead to avoid force-push conflicts.

Best Practices for Git Branching

Good branching habits make repositories easier to navigate, review, and maintain. These practices are distilled from real teams shipping software at scale.

Naming conventions

Branch names are read by humans and parsed by CI systems. See also 10 Best Practices for Git Branch Naming every developer should follow. Use a consistent, hierarchical naming scheme:

TypePatternExample
Featurefeature/<description>feature/user-notifications
Bug fixfix/<issue-or-desc>fix/login-redirect-loop
Hotfixhotfix/<version-or-desc>hotfix/v3.2.1
Releaserelease/<version>release/4.0.0
Chore/refactorchore/<description>chore/upgrade-webpack
Experimentexperiment/<description>experiment/webassembly-render

Naming Rules

Use lowercase letters and hyphens only. Avoid spaces, dots, and special characters (some CI systems choke on them). Keep names under 50 characters. Include a ticket number when applicable: feature/JIRA-1234-dark-mode.

When to delete branches

Stale branches are repository clutter. Delete them after merging — both locally and on the remote:

Clean up merged branches
# Delete local branch (safe — refuses if unmerged)
git branch -d feature/payment-gateway

# Force delete (use when branch was squash-merged or rebased)
git branch -D feature/payment-gateway

# Delete remote branch
git push origin --delete feature/payment-gateway

# Prune stale remote-tracking references locally
git fetch origin --prune

# List merged branches you can safely delete
git branch --merged main

Keeping branches clean

  • Short-lived branches: Aim to merge within a few days. The longer a branch lives, the harder it becomes to merge back.
  • Single purpose: One branch = one concern. Don’t mix a feature and an unrelated refactor in the same branch.
  • Small, frequent commits: Commit logical units of work, not entire features in one shot — this makes review and bisect much easier.
  • Rebase before merging: Keep your feature branch up to date with main by rebasing regularly, so the final merge is clean.
  • Protect main: Configure GitHub branch protection rules — require PR reviews, passing CI, and no direct pushes to main.

Quick Summary: Git Branch Commands Cheat Sheet

Every scenario covered in this guide — one command per row, no preamble needed.

Creating Branches

ScenarioCommand
Create branch (no switch)git branch <name>
Create + switch (classic)git checkout -b <name>
Create + switch (modern)git switch -c <name>
Create from another branchgit switch -c <name> <source-branch>
Create from specific commitgit switch -c <name> <commit-sha>
Create from taggit switch -c <name> <tag-name>
Create from remote branchgit switch -c <name> origin/<branch>

Switching & Listing

ScenarioCommand
Switch to existing branchgit switch <branch>
Show current branchgit branch –show-current
List local branchesgit branch
List all (local + remote)git branch -a
List with tracking infogit branch -vv

Remote Operations

ScenarioCommand
Push + set upstreamgit push -u origin <branch>
Push (after upstream set)git push
Fetch all remote branchesgit fetch origin
Delete remote branchgit push origin –delete <branch>
Prune stale remote refsgit fetch origin –prune

Cleanup

ScenarioCommand
Delete merged local branchgit branch -d <branch>
Force delete local branchgit branch -D <branch>
List merged branchesgit branch –merged main
Rename current branchgit branch -m <new-name>

The Golden Rule

Always pull the latest changes from your base branch before creating a new branch, and always push with -u on the first push. These two habits alone prevent the majority of branch-related headaches.

Also read about the best branching Git workflow to follow with 7 proven strategies used by top developers and teams.

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x