Create A Branch From Another Branch

Branching is the cornerstone of modern version control, allowing developers to isolate work, experiment safely, and collaborate without stepping on each other's toes. While creating a branch from the default main or master branch is the standard workflow, real-world development often requires a more nuanced approach: creating a branch from another branch. This technique is essential for feature stacking, hotfixes based on release candidates, or continuing work from a colleague’s unmerged pull request. Mastering this workflow ensures a clean history and prevents integration headaches down the line The details matter here. Took long enough..

Understanding the Git Branching Model

Before diving into the commands, it helps to visualize what a branch actually is in Git. Unlike other version control systems that copy files between directories, a Git branch is simply a lightweight movable pointer to a specific commit. When you create a new branch, you are creating a new pointer at the exact same commit your current HEAD is pointing to.

When you create a branch from another branch, you are telling Git: "Start this new line of development from the exact snapshot where the source branch currently sits." This means the new branch inherits the entire commit history, file changes, and directory structure of the source branch at that specific moment.

This distinction is critical. If feature-login has three commits ahead of main, and you branch feature-profile from feature-login, feature-profile starts with those three commits already baked in. This is powerful for dependency management but requires discipline to avoid "dependency hell" during code reviews.

The Standard Command Syntax

The most direct way to create a branch from another branch uses the git branch command followed by git checkout (or the modern git switch). The syntax requires specifying the new branch name and the source branch name (the start point).

Method 1: The Two-Step Classic Approach

This method works on all Git versions and is explicit about what is happening Simple, but easy to overlook..

# Syntax: git branch  
git branch feature-payment-integration feature-user-auth

# Switch to the new branch
git checkout feature-payment-integration

Method 2: The Modern Single Command (Git 2.23+)

Modern Git versions introduced git switch (and git restore) to separate "changing branches" from "restoring files," reducing confusion. This is now the recommended way to switch branches.

# Syntax: git switch -c  
git switch -c feature-payment-integration feature-user-auth

The -c flag stands for "create." If you omit the source branch name, Git defaults to the current HEAD. By explicitly providing feature-user-auth, you anchor the new branch there, regardless of which branch you are currently standing on.

Method 3: The Legacy Shortcut (git checkout -b)

You will still see this widely used in tutorials and older muscle memory. It combines creation and switching in one command Small thing, real impact..

git checkout -b feature-payment-integration feature-user-auth

Pro Tip: You don't need to be on the source branch to branch from it. You can be on main, run git switch -c new-branch feature-old, and the new branch will point exactly where feature-old points. This saves you the step of checking out the source branch first Surprisingly effective..

Practical Scenarios: When to Use This Workflow

Knowing how to run the command is easy; knowing when and why separates junior developers from seniors. Here are the most common professional scenarios.

1. Stacked Features (Dependent Development)

Imagine you are building an e-commerce checkout flow.

1. Branch A (feat/cart-api): Implements the backend API for the shopping cart.
2. Branch B (feat/cart-ui): Builds the frontend components consuming that API.

You cannot effectively work on Branch B until Branch A exists. Plus, * Benefit: You work with the latest API contracts immediately. Instead of waiting for Branch A to be reviewed, approved, and merged into main, you create Branch B from Branch A.

• Risk: If Branch A changes significantly during review (rebasing, force pushes), Branch B must be rebased onto the updated Branch A.

2. Hotfixes from a Release Branch

Your team uses a release/v2.0 branch for stabilization. A critical bug is found in production (which is currently on release/v1.9). You need to fix it on the upcoming release and the current production branch.

1. Create hotfix/login-crash from release/v2.0.
2. Apply fix.
3. Merge to release/v2.0.
4. Cherry-pick or merge to release/v1.9 (or main depending on strategy).

3. Collaborating on a Colleague's PR

A teammate opens a Pull Request (PR) for feat/new-dashboard. You need to add a reporting module that depends on their new data models. You fetch their remote branch and create your local branch from it:

git fetch origin
git switch -c feat/reporting-module origin/feat/new-dashboard

Now your work is based on their exact code. When they update their PR, you rebase your branch onto their updated remote branch.

The Critical Concept: Upstream Tracking and Remote Branches

When you create a branch locally from another local branch, the new branch has no connection to the remote repository (GitHub, GitLab, Bitbucket) until you push it Nothing fancy..

Pushing for the First Time

When you are ready to share your work or open a PR, you must push the branch and set the upstream tracking reference.

git push -u origin feature-payment-integration

The -u (or --set-upstream) flag links your local branch to the remote copy. Future git pull and git push commands will work without arguments Practical, not theoretical..

What Happens to the "Parent" Branch Relationship?

Git does not permanently record "this branch was created from that branch" in the metadata once the commit history diverges. The relationship exists only in the commit graph (DAG - Directed Acyclic Graph) Worth knowing..

• If you run git log --oneline --graph, you will see the shared history.
• If you delete the source branch (feature-user-auth), feature-payment-integration remains perfectly intact because it points to the commits, not the branch label.

That said, for Pull Requests, platforms like GitHub do track the "base branch." When you open a PR for feature-payment-integration, the UI will default the "base" to your repository's default branch (main). You must manually change the base branch in the PR UI to feature-user-auth if you want the diff to show only your new changes (the delta between the two feature branches).

Keeping Your Branch Updated: Rebasing vs. Merging

Since your branch depends on another feature branch, the source branch will likely receive updates (code review fixes, rebases, new commits). You must synchronize your branch to avoid massive conflicts later That alone is useful..

Option A: Rebasing (Preferred for Clean History)

Rebasing replays your commits on top of the updated source branch. This keeps history linear And that's really what it comes down to..

# 1. Ensure you have the latest source branch locally
git fetch origin
git checkout feature-user-auth
git pull origin feature-user-auth

# 2. Switch to your branch and rebase
git checkout feature-payment-integration
git rebase feature-user-auth

# 3. Force push (required because history was rewritten)
git push --force-with-lease

Warning: Only rebase branches that you own and nobody else is working on. Force-pushing rewrites history and breaks things for collaborators.

Option B: Merging (Safer for Shared Branches)

If others are committing to feature-payment-integration, merge