Git Rebase Onto Vs Interactive

Legacy context

This site is an independent educational reference focused on document-database and XML technical topics. Its preserved archive reflects a period when schema flexibility, validation, and query expression depth were central concerns for practitioners evaluating XML storage options. The material here discusses concepts such as XML schema definition, validation practices, and the use of SQL/XML functions like XMLTABLE with XQuery expressions, including FLWOR patterns.

The archive does not represent an active vendor, product line, or service. It is presented as a historical record of technical discussion, useful for understanding how these topics were approached in earlier database and markup contexts. No current certifications, customers, or operational claims are made. Readers interested in modern equivalents should consult contemporary documentation and community resources. The content is offered for educational and reference purposes only, without endorsement of any specific tool or platform.

Git Rebase Onto vs Interactive: A Practical Comparison. When you work with Git, `rebase` is one of the most powerful—and misunderstood—tools. Two common variants are `git rebase --onto` and `git rebase -i` (interactive). They solve different problems, but people often confuse them because both rewrite commit history. This guide explains what each does, when to use which, and the mistakes that trip up even experienced developers.

`git rebase --onto` is a non-interactive, surgical command. Its syntax is:

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

It takes the commits that exist *after* `<old-base>` up to the tip of `<branch>`, and replays them on top of `<new-base>`. The key insight: you are not moving a branch to a new base in the usual sense. You are *selecting a range of commits* and transplanting them elsewhere.

Example scenario: You have a feature branch `feature/X` that was accidentally branched from `main` at commit `A`, but you wanted it to be based on `release/1.2` which contains commit `B`. If `feature/X` contains commits `C` and `D` after `A`, you run:

git rebase --onto release/1.2 A feature/X

Result: commits `C` and `D` are replayed on top of `release/1.2`. The original `A` is no longer in the history of `feature/X`.

This command is ideal for:

• Moving a branch to a different upstream (e.g., from `main` to a release branch).
• Removing a merge commit or a bad commit from the middle of a branch without interactive editing.
• Splitting a long-lived branch: you can take the last few commits and transplant them to a new branch.

What git rebase -i (Interactive) Does

Interactive rebase opens an editor showing a list of commits in the range you are rebasing. You can reorder, squash, fixup, edit, drop, or reword commits. The default range is from the merge-base of your current branch and the upstream you specify, up to `HEAD`.

Typical invocation:

git rebase -i HEAD~5

This shows the last 5 commits. You change the action keywords (pick, squash, reword, etc.), save, and Git replays the commits according to your instructions.

Interactive rebase is for *history cleanup*, not for changing the base. You can change the base too, but the primary use cases are:

• Squashing multiple small commits into one logical commit.
• Rewording commit messages for clarity.
• Reordering commits to make logical sense.
• Dropping a commit that should not exist.
• Editing a commit to fix a mistake before it was made public.

The mental model is simple:

• `git rebase --onto` answers: "I know exactly which commits I want to move, and I know exactly where I want them to go. No questions asked."
• `git rebase -i` answers: "I want to rewrite the commits in this range, and I need to decide what to do with each one."

`--onto` is deterministic. It does not ask you to choose actions per commit. It just replays the whole range. Interactive is a manual, step-by-step process.

You can combine them: `git rebase -i --onto <new-base> <old-base> <branch>` is valid. That gives you an interactive session where the base is changed, and you can also edit the commit list. But in practice, most people use them separately.

Decision Criteria: Which One Should You Use?

Use `git rebase --onto` when:

1. You need to change the parent of a branch. For example, you branched from `main` but `main` has moved, and you want to rebase onto `origin/main` but *skip* a specific commit that is now in `main` (like a revert). A plain `git rebase main` would replay your commits on top of the new `main`, but if you want to exclude a commit that is already in `main`, `--onto` lets you specify an old base that excludes it.