Interactive Rebase

Use Interactive Rebase to clean up the history of the current branch. You can change the order of commits, combine commits, edit commit messages, change or split a commit, and remove commits. Git applies the commits again in the order you choose. Zide shows you the plan first, and nothing is pushed.

Open a plan

You can start a plan from three places:

In Commits, right-click a commit. Click Interactive Rebase from Here…. The plan includes that commit and every later commit on the current branch. The rebase starts from the commit immediately before the one you picked. If you pick the first commit of the branch, the plan includes every commit on the branch.
In the Commit view, click the More actions menu. Click Interactive Rebase from Here….
In Branches, right-click another branch. Click Interactive rebase onto this branch…. The plan includes the commits on the current branch that are not on the other branch. When you start the rebase, Git applies these commits onto the other branch. The other branch does not change.

Zide opens the Interactive Rebase tab. In a plan onto another branch, a line below the title names that branch and the commit it points at now. In a plan from the first commit, a line below the title says that the plan includes every commit on the branch. A change to an early commit gives that commit and every commit after it a new ID, so use this plan mainly for history that you have not shared.

While the plan’s branch is checked out, the Project Header shows Rebase plan: and the branch in place of the Branch control. Click Show Plan beside it to go to the plan. Click the label to open its menu, which holds Show Plan and Discard Plan.

Press Escape while the menu has focus to close it and return focus to its label. The paused-rebase menu closes the same way.

Each repository can have one plan, in its Interactive Rebase tab. Zide asks before it replaces a plan you changed, and before it opens a plan with more than 200 commits.

You can switch branches while you plan. The plan rewrites the branch it was built for, so it cannot start while another branch is checked out. The tab says which branch it rewrites and which one is checked out, and Start Rebase stays disabled until you switch back. You can keep arranging the plan in the meantime. The Project Header shows the ordinary Branch control while you are on another branch.

Keep or discard a plan

Zide saves the plan while you edit it, in the repository’s Git folder. When you restart Zide, or close the Project Tab and open the project again, the Interactive Rebase tab opens again with the plan. Zide then checks the commits again before you can start the rebase.

Before the rebase starts, closing the Interactive Rebase tab discards the plan. If you changed the plan, Zide asks first: click Keep Plan to keep the tab and the plan, or Discard Plan to close the tab and delete the plan. After the rebase starts, closing the tab keeps the plan without asking, so that Abort rebase… can bring it back.

In the tab, click Reset Plan to put the commits back in their original order with every action set to Pick, which also discards the messages you wrote. To delete the plan and keep the tab open, click More actions at the right of Start Rebase, then Discard Plan. The tab then says No rebase plan. Both ask first when you changed the plan.

If you change the plan in another Zide window, a window that shows an older copy does not save over it. When you next change the plan there, the tab shows the saved plan and says This plan was changed in another window.

If the saved plan is from a newer version of Zide, or cannot be read, the tab says so and offers Discard Plan. Zide does not change the file until you discard it.

Each commit shows on one line. Click Toggle compact mode at the right of Plan · oldest first to expand the commits. The row with Plan · oldest first stays at the top while you scroll the plan.

A plan is not available in these conditions. Zide disables the menu item or shows the reason in the tab:

A merge, rebase, cherry-pick, revert, or patch series is in progress.
You have a commit checked out instead of a branch, or the branch has no commits.
The selected commit is not on the current branch.
The commits contain a merge commit.
The branches share no earlier commit.
The repository is missing older commits the plan needs. Click Show in Git Overview, then Fetch Full History.
Git is not installed, or its version is earlier than 2.38.

Edit the plan

The list shows the oldest commit first. For each commit, select an action:

Action	Result
Pick	Keeps the commit and its message.
Reword	Keeps the commit. You edit its message.
Edit	Keeps the commit, then stops the rebase so you can amend it or split it into several commits. See Edit or split a commit.
Squash	Adds the changes to the commit above. You edit the combined message.
Fixup	Adds the changes to the commit above. Discards this commit’s message.
Drop	Removes the commit and its changes. The row stays in the list with its subject crossed out.

Squash and Fixup combine changes into the nearest commit above that uses Pick or Reword. The first commit that is not dropped must therefore use Pick, Reword, or Edit. A commit set to Edit cannot be combined, because the rebase stops at it before the rows below are added. Commits that become one commit are bracketed together under a heading such as Squash 2 commits → 1 commit, with the message for the result at the bottom. A line under each commit says what it adds. Click a commit hash to open that commit.

To change the order, drag a step by its handle. You can also use the row’s More actions menu. Click Move Up or Move Down. Click Open or Open in New Tab in the same menu to show the original commit.

In a plan for one commit, such as a plan from the latest commit, only Pick, Reword, Edit, and Drop can be used. Squash and Fixup need a commit above to combine into, so choosing one leaves the plan invalid and Start Rebase says why. To change the message of the latest commit, amend it instead. An amend keeps the commit in place and does not rewrite the rest of the branch.

A plan from the first commit must keep at least one commit, because there is no earlier commit for the branch to point to. If you drop every commit, a note above the list says so and Start Rebase is disabled. The first commit that you keep becomes the new first commit of the branch.

The count at the right of Plan · oldest first shows how many commits the plan makes.

Edit messages

A Reword step has a Commit message field. A group that includes Squash has one Message for the combined commit field. A Pick step with Fixup steps keeps its message, which shows without a field. The combined message starts with the full messages of the first commit and each Squash commit, in order. Each field has a Generate button that writes the message from the commits it covers, as in Staging. When the field already has text, you review the new message before it replaces yours, and Undo puts your text back.

A message you write for one commit stays with that commit. A message for a combined commit is made from the commits in its group, so changing which commits are in the group, or their order, writes it again from those commits. Put the group back as it was and your own message comes back with it.

Each message you edit needs a subject, which is its first line.

Fix an older commit

To correct a commit that is not the latest, commit the correction separately, then combine it into that commit with a rebase. This is Git’s fixup workflow.

In Staging, stage the correction.
In Commits, right-click the commit to correct and click Create Fixup Commit…. The dialog shows that commit, how many staged files the new commit takes, and the new commit’s message: fixup! and the subject of the commit you picked. Click Create Fixup Commit. Your Git hooks and commit signing settings apply, as for a commit from Staging.
The notification that follows has Autosquash in Rebase Plan. Click it to open a plan from the commit you corrected and run Autosquash on it. Or open any plan that includes that commit and click Autosquash. If you already changed an open plan for that commit, Zide keeps your plan and asks you to click Reload Plan first.
Check that the fixup commit is under the commit you corrected. Autosquash finds that commit again by its subject, so when several commits have the same subject, the fixup commit stays Pick with a note. Click Fixup into with the hash of the commit you corrected. Then click Start Rebase.

While a merge, rebase, cherry-pick, revert, or patch series is in progress, Create Fixup Commit… is disabled and its tooltip says why. Otherwise, when it cannot run, a notification says why: nothing is staged, the commit is not on the current branch, or a commit is checked out instead of a branch.

Autosquash

Autosquash shows at the right of Plan · oldest first when the plan has a commit whose subject starts with fixup!, squash!, or amend!. Click it to move each of these commits directly below the commit that its subject names:

Subject starts with	Action it gets
`fixup!`	Fixup: its changes are added and its message is discarded.
`squash!`	Squash: its changes are added, and its message is added to the combined message without the `squash!` line.
`amend!`	Fixup, and its message replaces the message of the commit it names, which is set to Reword. If you already wrote a message for that commit, Zide keeps your message and says so above the plan.

Autosquash looks for the named commit among the earlier commits of the plan: first a commit with that exact subject, then a commit with that hash, then a subject that starts with that text. A fixup of another fixup commit goes directly after it. Nothing runs until you click Start Rebase, and you can still change the plan. The Git setting rebase.autoSquash has no effect: the rebase runs the plan as it is shown.

A commit that Autosquash cannot place stays Pick, and a note under it says why:

Several commits match. Click Fixup into and the hash of the commit you mean. A squash! commit offers Squash into, and an amend! commit offers Fixup into … and replace message. When more than two commits match, the button opens a list.
The match comes after this commit. Fixup into moves this commit below it.
The match is before the plan. To combine the commits, open a plan from an earlier commit.
No commit matches.
The named commit is set to Drop or Edit, or is a fixup that is not placed yet. Change that, then click Autosquash again.

A commit that stays Pick is an ordinary commit and does not stop the rebase. The line above the plan says how many commits Autosquash arranged and how many remain as Pick. A note is hidden while the commit has another action and shows again when you set it back to Pick. When you click Autosquash again, Zide places the commits again and replaces the notes. Reset Plan removes the arrangement.

If the commits change while the plan is open, the plan asks you to click Reload Plan, and Autosquash is disabled until you do. Click Autosquash after the reload. If you clicked Autosquash and Zide found that the commits had changed, Autosquash runs by itself after you click Reload Plan.

Start the rebase

Read the notes above the list. Zide adds one when the commits are already on a remote branch, because updating that branch afterwards needs a force push, which replaces the history it published. It adds another when a commit in the range has no changes, because Zide keeps such a commit unless you drop or combine it.

Click Start Rebase. If the plan has a problem, the button is disabled and its tooltip gives the reason.

Git then applies the plan, with the messages you wrote. A plan without Edit usually finishes without stopping, because Git stops only where you asked it to or where it cannot continue on its own: a conflict, or a step a hook or commit signing refuses.

A rebase needs a clean working tree, so commit or stash your changes first. Zide says so and stops if any are left. Editing files does not harm the plan itself. If the repository keeps changing while Zide tries to start, the plan says so and waits for you to click Start Rebase again.

If the commits themselves change, the plan says so and Start Rebase waits. Click Reload Plan. Zide keeps your actions, your order and your messages for the commits that are still in the same places at the start of the range. New commits arrive as Pick. A Squash or Fixup becomes Pick when the commit it would combine into is no longer the one you chose, so nothing lands in a commit you did not pick for it. Work on a commit that is gone goes with it. If the older commits themselves changed, none of the plan can be matched up and Zide starts it again from the current commits. The plan then says what changed, and Zide asks first when the reload loses something. A reload needs the commit the plan starts from, or the branch it rebases onto, to still be there. If that commit is gone or no longer on the branch, the tab says why the commits cannot load. Start a new plan from Commits or Branches.

Edit or split a commit

When the rebase reaches a commit set to Edit, Git applies it and stops. The tab says Rebase stopped to edit at step 2 of 5., for example, and the row shows Editing. The Project Header shows Continue, and its menu is headed Rebase stopped to edit. There is nothing to skip, so Skip is not available.

If the commit conflicts, the rebase pauses for the conflict first. Resolve it and click Continue. Zide then commits the step and stops for the edit. It does the same after a hook or commit signing refuses the step’s commit and you fix the cause. If your resolution leaves no changes, there is nothing to edit: Git leaves the commit out and continues the rebase without stopping.

Open Staging. When the rebase stops, Staging selects Amend and shows the commit’s message. If you had already typed a commit message, Staging keeps Commit selected; click Amend to change the stopped commit.

To change the commit, stage the changes you want in it and edit the message if needed. Click the button at the bottom of Staging, such as Amend Message, then click Amend in the dialog. See Staging.
To split the commit, open the Staging More actions menu and click Undo Last Commit…. The commit’s changes stay staged, and Staging switches to Commit. Unstage what belongs in a later commit, commit the rest, then stage and commit the next part. Repeat until every part is committed.
To remove the commit, undo it, unstage its changes, and discard them. Then click Continue. The rebase continues without that commit.

Undo Last Commit… and Amend change only the stopped commit and the commits you make in its place. They are disabled at the commit before it.

When the stopped commit is the first commit of the branch, you can amend it, but you cannot split or remove it. There is no earlier commit to undo it to, so Undo Last Commit… is disabled. You can still undo commits that you add after it.

Click Continue when you are done. Continue stays disabled, and its tooltip says why, until:

No file is conflicted.
You committed, stashed, or discarded every staged and unstaged change. A new file you did not stage does not stop Continue.
HEAD is on the stopped commit, on commits you made after undoing it, or on the commit before it when you removed the commit. If you checked out another commit, check out the one the tooltip names again.
The branch you are rebasing is where it was when the rebase started.

To give up the rebase, abort it. Git puts the branch back as it was before the rebase, and the commits you made during the stop are discarded.

Closing the tab or restarting Zide keeps the stop. Reopen the plan from the Project Header menu with Show Rebase Plan.

Conflicts and recovery

When the rebase stops, the Interactive Rebase tab says so and names the step, for example Rebase paused at step 2 of 5. The plan below marks each step Finished, Paused, or Not started, and a dropped commit Removed. The step Git stopped on says what to do about it.

If conflicts stopped it, click the action that counts them, such as Resolve 2 files, in the tab or in the Project Header. Zide shows those files in Staging. Open each one, resolve it in the diff, and stage the result. The action becomes Continue when nothing is left conflicted. Click it to finish the step.

To leave out the commit Git stopped on, with its changes, click Skip in the tab, or open the banner menu and click Skip this commit…. Zide asks first.

The banner menu is headed Rebase paused. It names Target, the commit the rebase builds on, and Incoming, the commit Git is applying now. It also holds Open Staging once nothing is conflicted, and the tab’s More actions menu holds Show Current Step, which scrolls to the paused commit. See Conflict banner.

The plan is read-only while the rebase is in progress. To reopen the plan, click the operation label in the banner. Click Show Rebase Plan. Closing the tab does not stop the rebase. Zide uses your reviewed messages when you continue, even after you restart Zide.

To stop a rebase that has already started, click Abort rebase… in the banner menu, or Abort rebase… in the tab’s More actions menu, then confirm. Git puts the branch and its tracked files back as they were before the rebase. The conflicts you resolved during it are discarded. Zide then shows your plan again in the Interactive Rebase tab, also if you closed the tab, with The rebase was aborted and the branch is unchanged. above it. You can change the plan and click Start Rebase again.

While the rebase is in progress, Discard Plan in the tab’s More actions menu is disabled. To stop the rebase and delete its plan, click Abort rebase… first, then Discard Plan.

If a hook or commit signing refuses a step after the rebase starts, fix what it reports and click Continue. If Zide says the rebase did not start, fix the cause and click Start Rebase again.

When the rebase finishes, the tab says so, and Zide deletes the saved plan. After a rebase onto another branch, it also names that branch and its commit, for example Rebase complete onto main at b4a5c94. Click Show in Commits to show the result.

Compare the commits before and after

Below the result, Commits before and after lists the commits that the rebase rewrote, as they were before and as they are after, with the counts, for example (4 commits became 2 commits). It does not list the rest of the branch. Before rebase and After rebase each show two commits: the commit that the range starts after, which is not in the list, and the last commit of the range.

Git pairs commits that are similar enough on the two sides. This is the comparison that git range-diff makes. Each row has one of these results:

Result	Meaning
Unchanged	Git paired the commits. Their changes and messages are the same.
Changed	Git paired the commits. Their changes or messages are different.
Added	A commit after the rebase that Git did not pair with a commit before it.
Removed	A commit before the rebase that Git did not pair with a commit after it.

A pair is Git’s match by similarity, not a record of your plan. For example, when you squash two commits, the combined commit can pair with one of them, and the other then shows as Removed. If the combined commit is too different from both, it shows as Added and both earlier commits show as Removed. A commit that you dropped usually shows as Removed.

Click a Changed row to open it in a Diff tab. The left side shows the commit before the rebase and the right side shows the commit after it: the author, the message, and the changes to each file. Click a commit hash to open that commit.

Zide shows up to 256 KB of each commit in the Diff tab. When a commit is larger, both column labels end with (shortened), and changes after that point are not shown. Click the commit hash to see the whole commit.

The list stays until you start another plan or close the tab. Zide does not keep it after a restart. Git keeps the commits from before the rebase for some time and can then remove them. If you open a pair after Git removed its earlier commit, the row says Could not load the difference. Zide does not download the commit.

While Git compares the commits, click Cancel to stop. Zide compares up to 250 commits on each side, and it does not compare commits across a merge. A rebase from the first commit has no list, because there is no earlier commit to compare from. Comparing needs Git 2.19 or later.

A rebase started in a terminal

The Project Header also shows a rebase started outside Zide. Its Continue, Skip this commit…, and Abort rebase… actions use Git’s existing plan. Show Rebase Plan is available only for a plan started in Zide.

An external interactive rebase can pause when a commit becomes empty because its changes are already present. Continue or Skip can reach another such commit and pause again. Check Incoming in the menu for the commit Git is now applying. To leave that commit out, choose Skip this commit…. To keep an empty commit, run git commit --allow-empty in the terminal, then continue the rebase.

To abandon the rebase, use Abort rebase… or git rebase --abort. Do not delete Git’s rebase state directory: that does not restore the branch to its starting point.