Introduction

If one Git branch has child branches stacked on top of it, rebasing the parent does not automatically move the children. Each child branch still points to commits built on the old parent history. So rebasing a branch "including all its children" really means rebasing the stack in dependency order from the bottom up.

Understand the Branch Stack

Suppose you have this branch relationship:

• 'main'
• 'feature-a based on main'
• 'feature-b based on feature-a'
• 'feature-c based on feature-b'

If you rebase only feature-a onto updated main, then feature-b and feature-c still point to the old feature-a history. They are not magically rewritten.

That is why stacked branches need a deliberate sequence.

The Basic Bottom-Up Workflow

The usual pattern is:

1. rebase the lowest branch onto the new base
2. rebase the next branch onto the rewritten lower branch
3. continue upward through the stack

Example:

1git switch feature-a
2git rebase main
3
4git switch feature-b
5git rebase feature-a
6
7git switch feature-c
8git rebase feature-b

This works when each child branch should continue to depend on the updated version of its parent branch.

Using --onto to Be Explicit

git rebase --onto is useful when you want to say exactly what old base is being replaced with what new base.

For example, if feature-b was originally based on the old feature-a, and now you want it moved onto the new feature-a:

git switch feature-b
git rebase --onto feature-a old-feature-a-base feature-b

Conceptually, this means:

• take the commits in feature-b after old-feature-a-base
• replay them onto feature-a

This is especially helpful when the branch relationships are not obvious anymore.

Why Order Matters

Rebasing top-down is usually wrong for a stack. If you rebase feature-c before feature-b, then feature-c is still being replayed on top of an outdated intermediate base.

Bottom-up order matters because each branch depends on the rewritten history of the one below it.

That is the core rule:

• update parents first
• update children after their parents have their final history

Check the Stack Before Starting

Before rebasing, inspect the current branch graph:

git log --oneline --graph --decorate --all

This is important because many rebasing mistakes come from misunderstanding which branch actually branched from which commit.

If the stack is complicated, write down the intended order before changing history.

After the Rebase: Force Push Carefully

If these branches have already been pushed, rebasing rewrites commit history. That means updating the remote branches usually requires a force push.

git push --force-with-lease origin feature-a
git push --force-with-lease origin feature-b
git push --force-with-lease origin feature-c

--force-with-lease is safer than plain --force because it checks that the remote still looks like what you expect.

When Rebasing the Whole Stack Is a Bad Idea

If other developers are actively working on those child branches, rewriting the entire stack may create a lot of disruption. In those cases, a merge or a more coordinated workflow may be safer.

Rebasing is powerful, but it is also history rewriting. Use it when the stack is private or when the team agrees on the rewrite.

Common Pitfalls

The biggest mistake is assuming rebasing a parent branch automatically updates its child branches. It does not.

Another mistake is rebasing the stack in the wrong order. Child branches should usually be rebased only after their parent branches have been rewritten.

People also forget that remote branches need force-push updates after a history rewrite. Without that, the local and remote views diverge awkwardly.

Finally, do not start rebasing a stack without first understanding the actual branch graph. Guessing the parent-child relationships is how confusing conflicts multiply.

Summary

• Rebasing a branch does not automatically rebase its child branches.
• Rebase stacked branches from the bottom up.
• Use git rebase --onto when you need explicit control over old and new bases.
• Inspect the branch graph first so you know the real dependency order.
• If the branches are already pushed, update remotes carefully with --force-with-lease.