How to Create a New Branch in Git (Step-by-Step Guide)

Creating a new branch in Git is one of the most common tasks in modern software development. Branches let you work on new features, experiments, or bug fixes without touching the main code until you’re ready.

This guide explains what branches are, how they work, and how to create and use them safely. We’ll cover both the command line and GUI tools so you can match it to your comfort level.

What Is a Branch in Git and Why Use One?

In Git, a branch is simply a pointer to a series of commits (saved changes). You can think of it like:

• The main branch (often called main or master) is the official timeline of your project.
• A feature branch is a side path where you can:
  • Add a feature
  • Fix a bug
  • Try an experiment

Because Git branches are lightweight, you can create many of them without slowing down your project.

Typical uses for branches:

• Feature work: feature/user-login
• Bug fixes: bugfix/login-timeout
• Experiments: experiment/new-ui-layout
• Release prep: release/v2.0

The key benefit: you can commit freely on your branch without risking the stability of your main code.

Basic Git Branch Commands You Need to Know

These are the core commands related to branches:

• Create a new branch (without switching to it):

  git branch <branch-name> 

• Create and switch to a new branch in one go:

  git checkout -b <branch-name> 

  or with newer Git:

  git switch -c <branch-name> 

• Switch to an existing branch:

  git checkout <branch-name> 

  or:

  git switch <branch-name> 

• List branches:

  git branch 

• Delete a local branch (after merging or when no longer needed):

  git branch -d <branch-name> 

  Force delete (use with care):

  git branch -D <branch-name> 

• Push a new branch to a remote (e.g., GitHub):

  git push -u origin <branch-name> 

These commands work the same on most systems (Windows, macOS, Linux) as long as Git is installed.

Step-by-Step: How to Create a New Branch in Git (Command Line)

1. Check Your Current Branch and Status

Before creating a new branch, see where you are:

git status 

• This shows your current branch name and any uncommitted changes.
• It’s best to commit or stash changes before branching so your new branch starts from a clean point.

2. Make Sure Your Base Branch Is Up to Date

Usually, you branch off from main or another stable branch.

git checkout main git pull 

or, with switch:

git switch main git pull 

This ensures your new branch starts from the latest code.

3. Create and Switch to the New Branch

To create a new branch and immediately move onto it:

git checkout -b <branch-name> 

Example:

git checkout -b feature/add-profile-page 

With newer Git versions, you can use:

git switch -c feature/add-profile-page 

Now:

• You are on feature/add-profile-page
• Any new commits will go to this branch, not main

4. Work and Commit on the New Branch

Make your changes, then:

git add . git commit -m "Add profile page layout" 

These commits now belong to your feature branch, safely separated from main.

5. Push the New Branch to a Remote (Optional but Common)

If you’re using a remote repository (GitHub, GitLab, Bitbucket, etc.) and want to share the branch:

git push -u origin feature/add-profile-page 

• origin is the default name for your remote.
• -u sets up tracking, so later you can just run git push or git pull without specifying the branch.

Creating a Branch from a Specific Commit or Tag

You don’t have to branch only from main. You can start a branch from any commit, tag, or existing branch.

Branch from a Specific Commit

Get the commit hash using:

git log --oneline 

Then create a branch from that commit:

git branch hotfix/rollback 1a2b3c4 git checkout hotfix/rollback 

(or using switch after creating)

Branch from a Tag

If your project uses tags for releases:

git branch bugfix/v1.2-crash v1.2.0 git checkout bugfix/v1.2-crash 

This is useful if you need to fix something in an older release line.

Naming Your Git Branches: Things to Consider

Branch names don’t affect Git’s core behavior, but they matter for clarity.

Typical patterns:

Common best practices:

• Use lowercase and hyphens or slashes between words.
• Avoid spaces and special characters.
• Include a ticket/issue number if you use a tracker, like: feature/123-add-search-filter.

The “right” naming convention depends on how your team works and what tools you use around Git.

Creating New Branches in Git GUIs (GitHub Desktop, VS Code, etc.)

If you prefer not to use the terminal, most Git tools make branching very visual.

In Visual Studio Code (VS Code)

With the Git integration:

1. Click the branch name in the bottom-left corner.
2. Choose Create new branch….
3. Enter the branch name.
4. Confirm to switch to it.

You can also:

• Use the Source Control panel
• Or the Command Palette (Ctrl+Shift+P or Cmd+Shift+P) and run “Git: Create Branch…”

In GitHub Desktop

1. Open your repository.
2. Click the Current Branch dropdown.
3. Select New Branch.
4. Enter the branch name and the base branch (e.g., main).
5. Click Create Branch.

The tool will automatically switch you to the new branch and can help you publish it to GitHub.

In Other GUI Tools

Most Git apps (Sourcetree, GitKraken, IDEs like IntelliJ, Android Studio) follow a similar flow:

• Choose New Branch from a toolbar or branch menu.
• Select a base branch.
• Type a branch name.
• Confirm and switch.

Which tool you use depends on your operating system, editor preferences, and whether you like visual commit graphs or a simpler view.

Variables That Affect How You Create and Use Branches

The basic commands stay the same, but how you branch and organize work depends on several factors:

1. Your Operating System and Tools

• Windows vs macOS vs Linux: Git commands are the same, but setup steps and GUIs available differ.
• CLI vs GUI:
  • Command line gives you more control and is consistent everywhere.
  • GUIs can make branching, merging, and history viewing more intuitive.

2. Whether You Use Remotes (GitHub, GitLab, etc.)

• Local-only projects:
  • You may create and delete branches freely without worrying about collaboration.
• Team projects / remotes:
  • You’ll usually push branches to a shared server.
  • Branch naming, when to delete branches, and who can push where may be governed by team policies.

3. Your Branching Strategy

Teams often adopt a branching model, for example:

Your branching commands are the same, but:

• Which branch you start from changes (main vs develop).
• How long branches live and how often they’re merged depends on your strategy.

4. Your Skill Level and Comfort with Git

• Beginner:
  • Might use only git checkout -b, git add, git commit, git push.
  • Might prefer a GUI at first.
• Intermediate/advanced:
  • Will use options like:
    • git rebase to keep history cleaner
    • git cherry-pick to move individual commits between branches
  • Might script or alias common branching workflows.

5. Project Size and Risk Tolerance

• Small personal projects:
  • You might branch less and commit directly to main sometimes.
• Large or critical projects:
  • Strict rules about:
    • No direct commits to main
    • Mandatory branches and code reviews
    • Protected branches on remotes

All of these influence not just how you create branches, but when and how many you create.

Different Ways People Use Branches in Practice

Because Git is flexible, there’s a wide spectrum of branching habits:

• Minimalist approach:

  • One or two branches (main and maybe dev).
  • Occasional feature branches for bigger changes.

• Moderately structured:

  • Short-lived feature branches for almost every task.
  • Merge via pull requests or merge requests.
  • Branches deleted after merge to keep things tidy.

• Highly structured / enterprise setups:

  • Clearly defined branch types: feature/, bugfix/, release/, hotfix/.
  • Automated tests on each branch.
  • Protected main with required approvals and checks.

• Experiment-heavy workflows:

  • Many temporary branches with experimental code.
  • Some never merged; they’re used to try ideas in isolation.

Each approach uses the same core git branch and git checkout/git switch commands, but the rules, naming, and lifetimes of branches vary by team, risk level, and tooling.

Putting It All Together for Your Own Setup

Creating a new branch in Git always comes back to the same idea:

1. Decide what point in history you’re branching from (usually main or develop).
2. Run a simple command like:

   git checkout -b <branch-name> 

3. Commit your changes on that branch.
4. Optionally sync it with a remote.

How you name branches, which base branch you use, how long branches live, and which tools you use to manage them all depend on:

• Your operating system and editor
• Whether you work alone or in a team
• The branching strategy your project follows
• Your comfort level with the command line versus GUIs
• How critical or complex your codebase is

Once you understand the mechanics, the remaining step is to look at your own project, tools, and collaboration style and decide how branching should fit into that reality.