Introduction

When people say "rebase to a specific commit," they usually mean one of two different Git operations. Either they want to move the current branch so its commits sit on top of a different base commit, or they want to transplant only part of a branch onto a new base using --onto.

The Simple Case: Rebase the Current Branch onto a Commit

If you are on the branch you want to move, the simplest form is:

git switch feature
git rebase 8f3c2ab

This tells Git:

• find the commits that are on feature but not on 8f3c2ab
• replay those commits on top of 8f3c2ab

So if your history looked like this:

A---B---C main
     \
      D---E feature

and you rebase feature onto C, the result is effectively:

A---B---C main
         \
          D'---E' feature

The apostrophes matter because rebasing rewrites commits. The content may be the same, but the commit IDs change.

What Git Actually Uses as the Cut Point

git rebase <commit> does not blindly move every commit in the repository. It finds the merge base between your current branch and the target commit, then replays only the commits after that point.

That is why rebase is usually a branch operation, not a "pick arbitrary commit IDs and shuffle them around" operation.

If you only remember one rule, remember this one:

• 'git rebase <target> means "replay my current branch on top of target"'

Use --onto for More Precise Rebases

Sometimes you do not want to replay the whole current branch. You want to take a subset of commits and move only that part.

That is what --onto is for:

git rebase --onto <new-base> <old-base> <branch>

Example:

git rebase --onto main 8f3c2ab feature

This means:

• take commits on feature that come after 8f3c2ab
• replay them onto main

This is especially useful when a feature branch was based on the wrong commit or when you want to peel part of a stacked branch off from an earlier dependency.

Interactive Rebase from a Specific Commit

Sometimes "rebase to a specific commit" really means "rewrite commits after this point." In that case, interactive rebase is the better tool:

git rebase -i 8f3c2ab

Git will open an editor listing the commits after 8f3c2ab. You can then:

• reorder commits
• squash commits
• edit commit messages
• drop commits entirely

If you want to include the specific commit itself in the editable range, start from its parent:

git rebase -i 8f3c2ab^

That distinction is important because interactive rebase starts after the commit you name.

Conflict Handling During Rebase

If Git cannot replay a commit cleanly, it stops and asks you to resolve the conflict:

1git status
2# fix files
3git add path/to/file
4git rebase --continue

If you decide the whole idea was wrong:

git rebase --abort

That returns you to the pre-rebase state as long as the rebase is still in progress.

Be Careful with Shared Branches

Rebase rewrites history, which is fine on private feature branches but disruptive on branches other people already depend on.

If you rebase a branch that has already been pushed and shared, you will usually need:

git push --force-with-lease

That is safer than plain --force because it checks that the remote still looks the way you expect.

Even so, history rewriting on shared branches should be deliberate, not casual.

A Practical Workflow

When you want to move a feature branch onto the current main:

git fetch origin
git switch feature
git rebase origin/main

When you want to rewrite or clean up local commits after a known base:

git switch feature
git rebase -i origin/main

When you want to transplant only a subrange of commits:

git rebase --onto new-base old-base feature

These three patterns cover most real uses.

Common Pitfalls

• Using git rebase <commit> when you really need git rebase --onto.
• Forgetting that rebased commits get new commit IDs.
• Running interactive rebase from the target commit instead of its parent when you meant to edit that commit too.
• Rebasing a shared branch and then surprising teammates with rewritten history.
• Forgetting git rebase --abort exists when conflicts become too messy.

Summary

• 'git rebase <commit> replays your current branch on top of a new base commit.'
• 'git rebase --onto is the more precise form for moving only part of a branch.'
• 'git rebase -i <commit> is for editing commits after a known point.'
• Rebasing rewrites commit IDs, so treat pushed branches carefully.
• Once you understand which of the three forms you need, rebasing to a specific commit becomes much more predictable.