Clean Up Local Commits Before Pushing with Tower Interactive Rebase

What this guide solves

You have a local feature branch with several small commits—fixes, typos, and experiments—and you want to tidy them into a clear history before pushing to a shared repository. Rewriting history by hand in the terminal is error-prone, and a mistake can detach your work from the branch you intended to update.

Tower's Interactive Rebase lets you reorder, combine, reword, or remove commits through a visual list before applying them. The useful takeaway: you can preview and adjust the plan, then abort at any point before the rebase finishes. Do not use it on branches that other people have already pulled or built on, because rewriting published history forces everyone else to recover their local copies.

Desired outcome

Your current local branch contains a rewritten commit history that matches your intended order and messages, with no uncommitted changes left behind, and you know how to return to the pre-rebase state if something goes wrong.

Prerequisites

• Tower installed on macOS or Windows, with the repository open.
• The branch you want to rewrite is checked out and is local only, not shared with teammates.
• The working directory is clean: no uncommitted staged or unstaged changes.
• The branch contains at least two commits you intend to modify.
• Recommended: create a backup branch or tag at the current tip before starting.

Create a backup reference

Before rewriting, snapshot the current tip so you have a known-good commit to return to.

1. In Tower's History view, right-click the current branch tip commit.
2. Create a branch or tag from that commit, for example backup/pre-rebase.
3. Confirm the new reference appears in the sidebar or branch list.

Start an interactive rebase

1. In Tower, open the History view for the current branch.
2. Right-click the commit that should become the new base—typically the parent of the oldest commit you want to change.
3. Choose Interactive Rebase… from the context menu.
4. The Interactive Rebase dialog lists commits reachable from the current tip down to the selected base.
5. For each commit, set the action using the dropdown: pick, reword, edit, squash, fixup, or drop.
6. Drag rows to reorder commits where supported.
7. Click Start Rebase.

Action	Effect
pick	Keep the commit as-is.
reword	Keep the changes, change only the commit message.
edit	Pause after applying this commit so you can modify the contents.
squash	Combine the commit into the previous one and keep both messages for editing.
fixup	Combine the commit into the previous one using the previous message.
drop	Remove the commit entirely.

Handle an edit pause

If you selected edit for any commit, Tower pauses the rebase and shows a Rebase in progress banner. Make your changes in the working tree, stage them in Tower, then click Continue Rebase in the banner or toolbar. Tower applies the staged changes as part of the paused commit and moves to the next step.

Resolve conflicts during rebase

If a commit cannot apply cleanly, Tower opens its built-in conflict resolver. Resolve each conflicting file, mark it resolved, then continue. You can also click Abort Rebase in the banner at any time to return to the branch state before the rebase started.

Expected checks

1. Open Tower's History view and confirm the commit order, messages, and authors match your rebase plan.
2. Run git status in Terminal or Tower's working tree view. The output should show a clean working tree with nothing to commit.
3. Run git log --oneline -n 10 in the repository root to cross-check the most recent commits against Tower's History view. This command is read-only and does not modify the repository.
4. If the branch has a remote counterpart, run git diff origin/<branch-name> in Terminal before pushing. Replace <branch-name> with your branch, for example feature/login-flow. Review the diff to confirm only intended changes appear.

Recovery if the result is wrong

Interactive rebase rewrites history, so it changes repository state. Tower offers two ways to undo:

• Immediate undo: Press ⌘Z on macOS or Ctrl+Z on Windows right after the rebase finishes. This reverses the most recent Tower operation only.
• Reflog reset: If you closed the window or performed other actions, open Tower's Reflog (View → Show Reflog), right-click the commit that was the branch tip before the rebase, and choose Reset to this commit. Choose the reset mode appropriate for your situation, typically a hard reset if you want the working tree to match that commit exactly.

Alternatively, delete the rewritten branch and recreate it from the backup reference you created earlier.

Limitations

• Never run interactive rebase on a shared or public branch that others have based work on. Rewriting published commits requires force-pushing and forces collaborators to repair their local history.
• Tower's Undo applies only to the most recent operation. After closing the window or running other Git actions, use the reflog or backup branch instead.
• Large rebases with many conflicts can be slower in the GUI than on the command line. For complex history surgery across many commits, consider the terminal git rebase -i workflow.
• Tower's Interactive Rebase rewrites only the current branch. It does not automatically rebase descendant branches that were created from the old commits.

Practical verification

After the rebase, run git log --oneline --graph -20 in the repository root. Confirm the graph shows a sequence matching your reordered commits. If you plan to push, perform the remote diff check first, then push if the branch was never published, or force-push with care if you are replacing an earlier pushed version on a branch you own exclusively.