Interactive rebase
Interactive rebase, planned before Git runs.
Interactive rebase is how you tidy a branch before others read it: squash the fix into the commit it fixes, reword a vague message, drop an experiment. Nori turns Git’s todo file into a plan you edit in a list, and shows the history you will get before anything is written.
What git rebase -i does
git rebase -i main takes the commits your branch has on top of main and replays them one at a time. Before it starts, Git opens a todo list in your editor, oldest commit first:
pick 3f2a1c4 Add retry to the fetch client
pick 9b81e07 Fix typo in retry delay
pick c40d2aa Log every retryYou change the word in front of each line, reorder lines or delete them, save and close. Git then rebuilds the branch from that plan, and the old commits are replaced by new ones with new hashes.
The six actions
| Action | What happens to the commit |
|---|---|
| pick | Kept as it is. |
| reword | Kept, with a new message. |
| edit | Replayed, then the rebase stops so you can amend its files or split it. |
| squash | Folded into the commit above it; both messages are combined. |
| fixup | Folded into the commit above it; only that commit’s message is kept. |
| drop | Removed from the branch. |
How Nori plans a rebase
In the graph, open a commit’s menu and choose Rebase interactive … onto this. Nori lists every commit the rebase would replay, and each line takes one of the six actions, from a menu or a key. Reorder lines in the same list.
Beside the plan, the result column shows the history you will get. Choose Squash on a fix below its parent and the folded commit appears there with both commit messages, before Git has run anything. Reword lets you type the new subject in place.
The result column also states what the plan costs:
- Rewrites pushed commits. When the plan changes commits the upstream already has, Nori says how many, and that it will push with
--force-with-lease, which refuses to overwrite work someone else pushed meanwhile. - Stops. Each edit pauses the rebase so you can amend the tree, and the plan says how many times it will stop.
- The branch as it stands is kept. Nori writes
ORIG_HEADbefore the first line replays, so aborting puts every commit back where it was.
While the rebase runs
Until you press Start rebase, the plan lives only in Nori: close it and nothing has changed. From then on, the repository is the truth. Nori draws the screen from Git’s own todo and done lists, so quitting Nori mid-rebase, or having started the rebase in a terminal, leads to the same place.
If Git pauses, on an edit or on a conflict, continue, skip or abort from Nori. A conflict goes to the merge conflict resolver, and you can leave the rebase screen at any time: the graph’s banner and the resolver bring you back to it.
Rebase or merge?
Rebase rewrites your commits so the branch reads as if it started from the latest main; merge keeps both histories and records where they joined. Rebasing a branch only you use is safe. Rebasing commits other people have already built on forces them to reconcile their copies, which is why Nori names pushed commits before you start.
For a plain rebase without a plan, drop one branch on another in Nori’s graph: the menu names both branches, Rebase A onto B, before anything runs.
Limits
- The plan offers pick, reword, edit, squash, fixup and drop. Git’s other todo commands, such as
exec,breakorlabel, are not part of Nori’s plan; use the terminal for those. - Splitting a commit in two happens at an edit stop, where you amend the tree and commit the parts yourself.
- A finished rebase is not in Nori’s undo list. To go back, History lists the reflog, where the branch’s previous tip remains.