Create Branch

What Happens When You Create New Branch?

Create Local Branch

Creating a branch is easy and straightforward as this:

git branch feat/auth

That’s it, you just create a brand new feat/auth branch. But there is more…

Create Remote Branch

To create remote branch, you first create locally and push the changes.

git branch feat/auth
git push origin feat/auth

What Happens When You Create New Branch

When you create and switch to new branch (name it feat/auth), Git let’s you start fresh. This means any changes you introduce in your new feat/auth branch won’t affect files in your main or master branch. You need to manually merge it later. This is what makes the independent development in any feature branch without even touching main branch.

When you create new branch (name it feat), Git creates a new movable pointer which points to the same commit you are currently on.

What does it mean?

Let’s say, you are currently on master branch and it is the only branch in your project. And the commit history for this master branch looks like the following where master is pointing to your current point C.

    flowchart RL
    subgraph commits
    A
    B
    C
    C --> B
    B --> A
    end
    master --> C
  

Now you create a new branch feat. What happens is, feat points to the same commit C you are currently on.

    flowchart RL
    subgraph commits
    A
    B
    C
    C --> B
    B --> A
    end
    master --> C
    feat --> C
  

How Git Knows Which Branch You are Currently In?

Git actually keeps a special pointer named HEAD that points to your current branch. Git stores HEAD at .git/HEAD. Suppose, you are on branch master and cat .git/HEAD you will get:

ref: refs/heads/master

This means you are on master branch. But there is more. The output roughly translates to .git/refs/heads/master and when you look inside it, you will find the 40 character SHA-1 commit hash currently master is pointing to.

And when you switch to new branch feat, HEAD points back to feat/auth as shown by .git/HEAD

ref: refs/heads/feat

And yes you are right that .git/refs/heads/feat also has 40 character SHA-1 commit hash currently feat is pointing to.

Visualizing HEAD

If you want to visualize what HEAD is pointing to while you are in feat branch, this diagram is the answer:

    flowchart RL
    subgraph commits
    A
    B
    C
    C --> B
    B --> A
    end
    master --> C
    feat --> C
    HEAD --> feat
  

Why Create New Branch: Real World Use Cases

Branches aren’t just a Git feature for show, they solve real problems that come up daily in a development team. Here are some common scenarios:

Feature Development: Say you’re building a new payment gateway integration. Instead of writing code directly on main and risking breaking the live product, you create a feature/payment-gateway branch. You can commit as often as you like, experiment, even leave things half-broken overnight, without affecting anyone else’s work.

Bug Fixes in Production: Imagine your app is live and a critical bug is reported. Meanwhile, your main branch already has half-finished work for the next release sitting in it. You create a hotfix/login-crash branch straight from the last stable commit, fix the issue there, and merge it back without dragging in the unfinished feature work.

Experimentation: Want to try out a new library or refactor a core module but not sure if it’ll pan out? Create a throwaway branch like experiment/new-orm. If it works, merge it in. If it doesn’t, just delete the branch, no harm done to your actual codebase.

Parallel Team Collaboration: In a team of five developers, each person can work on their own branch (feature/search, feature/notifications, feature/user-profile) simultaneously, without stepping on each other’s toes. Everyone merges into main only when their work is tested and ready.

Code Review Workflow: Most teams don’t push straight to main. Instead, a branch is created, work is done, a Pull Request (PR) is opened against main, teammates review the code, and only after approval does it get merged. Branches are the backbone that makes this whole review process possible.

Industry Standard Naming Conventions of Branches

Once you start creating branches regularly, naming them randomly (test, new-stuff, johns-branch) turns your repo into a mess pretty quickly. Most teams follow a type/description pattern so anyone glancing at the branch list instantly understands what’s going on. Here’s the convention most companies converge on:

A few extra rules worth adopting:

• Use hyphens, not underscores or spaces. feature/user-profile is easier to read and click on in most Git tools than feature/user_profile or feature/user profile.
• Keep it short but descriptive. feature/search is fine. feature/adding-a-new-search-bar-to-homepage-for-users is not.
• Include ticket numbers if your team uses a tracker. Something like feature/PROJ-482-search-filters links the branch directly back to Jira, Linear, or whatever you’re using, which makes tracing work much easier later.
• Lowercase everything. Git is case-sensitive, and mixing cases (Feature/Search vs feature/search) leads to confusing duplicate-looking branches.