How to Make a New Branch in Git: A Clear Guide for Every Workflow

Git branches are one of the most powerful features in version control — and one of the most misunderstood by people just getting started. Whether you're working solo on a personal project or collaborating on a large codebase, knowing how to create and manage branches properly can make the difference between a clean history and a tangled mess.

What Is a Git Branch, Actually?

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

The default branch in most modern Git repositories is called main (older repositories often use master). Every new branch starts from some point in that history and grows independently from there.

This architecture is what makes Git so useful for:

• Feature development — building something new without touching stable code
• Bug fixes — isolating a fix so it doesn't break other work in progress
• Experimentation — trying ideas you might throw away
• Code reviews — letting teammates review changes before they merge

The Core Commands for Creating a New Branch 🌿

The Traditional Two-Step Method

The classic approach uses two separate commands:

git branch feature/my-new-feature git checkout feature/my-new-feature 

The first command creates the branch. The second switches your working directory to it. Simple, explicit, and easy to understand when you're learning.

The Shortcut: Create and Switch in One Line

Most developers quickly move to this combined command:

git checkout -b feature/my-new-feature 

The -b flag tells Git to create the branch and check it out simultaneously. Same result, fewer keystrokes.

The Modern Approach: git switch

Newer versions of Git (2.23 and later) introduced a dedicated command for switching branches that many developers prefer for clarity:

git switch -c feature/my-new-feature 

The -c flag stands for "create." This command does exactly what checkout -b does, but the intent is more readable — switch is harder to confuse with other operations that checkout also handles (like restoring files).

Branching From a Specific Starting Point

By default, a new branch starts from wherever HEAD currently points — meaning your current branch and commit. But you can branch from any specific point in history:

git checkout -b hotfix/login-bug main git switch -c hotfix/login-bug origin/main 

This creates a new branch starting from main (or a remote branch like origin/main) regardless of what you currently have checked out. This matters a lot when:

• Your current branch has uncommitted experimental work
• You need to create a fix based on the latest stable version
• You're branching from a tagged release rather than the tip of a branch

Naming Your Branch: Conventions That Matter

Git doesn't enforce branch naming rules, but teams almost universally adopt conventions. Common patterns include:

Using forward slashes in names creates visual grouping in many Git GUIs and doesn't cause problems in most environments. Avoid spaces, special characters, and names that start with a hyphen.

Pushing a New Branch to a Remote Repository

Creating a branch locally doesn't automatically share it with anyone. 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, which means future git push and git pull commands on this branch will automatically know where to push and pull from. You only need -u the first time.

Checking What Branches Exist 🔍

Before creating a branch, it's worth knowing what already exists:

git branch # List local branches git branch -r # List remote branches git branch -a # List all branches (local and remote) 

Your currently active branch will be highlighted (often in green) with an asterisk next to it.

Variables That Affect Your Branching Workflow

The mechanics above are consistent across Git installations, but how branching fits into your workflow depends on several factors:

Team size and collaboration model — Solo developers often work with fewer branches and simpler naming. Larger teams may follow strict conventions like Git Flow, GitHub Flow, or trunk-based development, each with different rules about how many branches exist at once and how long they live.

Repository host and tooling — GitHub, GitLab, and Bitbucket each have their own pull request / merge request workflows that shape how branches are reviewed and merged. Some teams use branch protection rules that prevent direct pushes to main.

Git version — The git switch command isn't available on older Git installations. If you're on a shared server or a legacy environment, git checkout -b remains the universally compatible option.

GUI vs. command line — Applications like GitHub Desktop, Sourcetree, and VS Code's built-in Git integration all offer point-and-click branch creation, which abstracts these commands entirely. The underlying operations are identical, but the interface and available options vary by tool.

Project branching strategy — Some projects discourage long-lived branches entirely (trunk-based development keeps everything close to main). Others rely on feature branches that live for days or weeks. The right approach is determined by your team's release cadence, code review process, and deployment pipeline.

Understanding the commands is the straightforward part. How they slot into your specific team's process — and which branching model actually reduces friction for your workflow rather than adding it — is where your own context becomes the deciding factor.