Introduction

If you want to rebase a branch but leave out one specific commit, the safest answer is usually an interactive rebase. That lets you edit the rebase todo list and drop the unwanted commit explicitly instead of trying to rewrite history with a more opaque command.

The Safe Default: Interactive Rebase

Suppose your branch history looks like this:

A - B - C - D - E

and you want to keep everything except C. Start an interactive rebase from the commit before the range you want to edit:

git rebase -i A

Git opens a todo list containing commits B, C, D, and E. It will look roughly like this:

1pick <hash-B> message for B
2pick <hash-C> message for C
3pick <hash-D> message for D
4pick <hash-E> message for E

To skip C, either delete that line or change pick to drop:

1pick <hash-B> message for B
2drop <hash-C> message for C
3pick <hash-D> message for D
4pick <hash-E> message for E

Save and close the editor. Git will replay the remaining commits and omit C.

Why Interactive Rebase Is Better

Interactive rebase is easier to audit because you can see the exact commit list before history changes. That matters when the branch contains more than a few commits or when you are dropping a commit in the middle of the stack.

If conflicts appear, resolve them, stage the fixes, and continue:

git add .
git rebase --continue

If you change your mind:

git rebase --abort

That makes the workflow much safer than trying to memorize a one-line history rewrite without seeing the commit list first.

A Narrower Shortcut With --onto

If you are certain you want to drop exactly one commit and keep everything after it, --onto can do it directly.

For the same history where you want to drop C:

git rebase --onto C^ C

This tells Git to replay everything after C onto C's parent, effectively removing C from the branch history.

That command is powerful, but it is less self-explanatory than an interactive rebase, which is why the interactive method is usually better for humans.

Be Careful With Shared Branches

Rebasing rewrites commit hashes. If the branch has already been pushed and other people may have based work on it, dropping a commit can disrupt their history.

If you must update the remote after rewriting:

git push --force-with-lease

Use --force-with-lease, not a blind --force, so you do not overwrite remote work you have not seen.

Common Pitfalls

• Starting the interactive rebase from the wrong base commit and editing the wrong range.
• Dropping a commit that later commits depend on, which creates conflicts or logical breakage.
• Forgetting that rebasing changes commit hashes and therefore affects pushed branches.
• Using --onto without first understanding exactly which commits Git will replay.
• Force-pushing rewritten history without checking whether teammates are using the branch.

Summary

• The safest way to skip one commit during rebase is usually git rebase -i.
• Delete or drop the unwanted commit from the rebase todo list.
• Use git rebase --continue for conflicts and git rebase --abort if needed.
• 'git rebase --onto can drop a specific commit directly, but it is easier to misuse.'
• Be especially careful when rewriting history that has already been shared with others.