Interactive Rebase Planner
Plan a clean git rebase - pick, squash, reword, drop.
- $25 Free
- 50 sec
- No signup
List your recent commits
Pick an action for each
Copy the rebase command + plan
You get: A rebase command + todo list to clean up your commit history.
Plan your rebase
Rebase rewrites history
Only rebase commits you have NOT pushed to a shared branch. Rewriting shared history forces teammates to reconcile. If you must, coordinate first.
Command + plan
git rebase -i HEAD~3
Your rebase todo list
pick a1b2c3d first commit (keep as the base) squash e4f5g6h later commit (fold into the one above) squash e4f5g6h later commit (fold into the one above)
Steps
- Leave the top line as pick - it becomes the combined commit.
- Change every line below it from pick to squash (or s).
- Save and close. Git opens a second editor to write the single combined message.
- Write the final message, save, and close. Your N commits are now one.
Interactive rebase, without the fear
Interactive rebase is the tool that turns a messy string of 'wip', 'fix typo', 'actually fix it' commits into a clean, readable history. It is also the git command people are most scared of, because it rewrites history and the editor it opens is cryptic if you have never seen it. This planner removes the guesswork: pick your scenario, and it gives you the exact rebase command, a sample todo list showing which keyword goes on which line, and the steps to finish safely.
It is a planner, not an executor. Everything is generated in your browser. You copy the command and run it yourself, so you always see what is happening before your history changes.
The rebase keywords, decoded
- pick - keep this commit as-is. This is the default for every line.
- reword (r) - keep the changes but rewrite the commit message.
- squash (s) - fold this commit into the one above it, combining both messages into one.
- fixup (f) - like squash, but discard this commit's message entirely and keep the one above.
- edit (e) - stop at this commit so you can change its contents, then continue.
- drop (d) - delete this commit (or just delete its line from the todo list).
The golden rule of rebase
Never rebase commits you have already pushed to a branch other people use. Rewriting shared history forces everyone else to untangle their copies. Rebase freely on local, unpushed work; use merge or revert on shared branches.
Squashing before you open a pull request
The single most common reason to rebase is cleanup before review. You have eight scrappy commits on your feature branch and you want reviewers to see one clean commit, or a handful of logical ones. Run git rebase -i HEAD~8, keep the first line as pick, and mark the rest squash. Git combines them and lets you write one clear message. Your reviewer sees a tidy diff instead of your entire thought process, and the main branch history stays readable for the next person who reads git log.
Rebasing onto an updated main
The other big use is keeping your branch current. While you worked, main moved ahead. Instead of merging main into your branch (which litters history with merge commits), you rebase: git fetch origin then git rebase origin/main. Git lifts your commits off, updates the base to the latest main, and replays your commits on top. The result is a straight line - your work sitting cleanly on top of the newest main, as if you had started from it this morning.
When a rebase hits a conflict
- Git pauses and tells you which files conflict. This is normal, not a failure.
- Open each conflicted file, resolve the markers, and save.
- Run git add on the files you fixed.
- Run git rebase --continue to move on to the next commit.
- If it all goes wrong, git rebase --abort returns you to exactly where you started, as if you never began.
Your safety net: reflog and abort
Two features make rebase far less scary than its reputation. First, git rebase --abort cancels an in-progress rebase and restores your branch to its pre-rebase state instantly. Second, git reflog records where your branch pointed before the rebase, so even a completed rebase can be undone by resetting to the old commit hash. Before any serious rebase, note your current hash with git rev-parse HEAD. With that written down, there is no rebase you cannot walk back.
Frequently asked questions
What is the difference between squash and fixup?
Both fold a commit into the one above it. squash keeps both commit messages and lets you edit the combined text; fixup silently discards the folded commit's message and keeps the one above.
Is it safe to rebase?
On local commits you have not pushed, yes - and git rebase --abort undoes an in-progress rebase completely. The danger is only rebasing commits that others have already pulled.
How do I undo a finished rebase?
Use git reflog to find the commit hash your branch pointed to before the rebase, then git reset --hard <that-hash>. Noting the hash beforehand with git rev-parse HEAD makes this painless.
What does HEAD~3 mean?
It means 'three commits back from the current tip'. git rebase -i HEAD~3 opens the last three commits for interactive editing.
Should I rebase or merge to update my branch?
Rebase gives a clean, linear history with no merge commits and is great for feature branches before review. Merge preserves the true timeline and is safer on shared branches. Many teams rebase locally, then merge the pull request.
Does this tool change my repository?
No. It only generates the command and the plan in your browser. You run everything yourself in your own terminal.
Liked this tool? The club is the next step.
Join Claude Code Club for $9/month. 650+ lessons, weekly updates, and the workflows behind every tool on this site.
- No experience needed
- Cancel anytime
- Updated weekly