Cleaning Up WIP Commits with Tower's Interactive Rebase (Without Fearing the Undo)

You know the moment: your feature branch works, but the history reads wip, fix typo, actually fix it, oops revert that. Before opening the pull request you want three tidy commits, not twelve confessions. Doing that with git rebase -i on the command line is perfectly doable, but plenty of engineers avoid it because one wrong pick line can feel unrecoverable. Tower — the commercial Git GUI for macOS and Windows — is worth a look precisely because it attacks that fear, not the underlying mechanics.

The useful takeaway: Tower's interactive rebase is the same git rebase -i machinery with drag-and-drop and a genuinely broad undo, so you can clean up local history confidently — as long as you keep the force-push discipline that no GUI can enforce for you.

Tower doesn't replace Git — it drives it

This is the point that makes the tool safe to recommend. Tower is a front end over the standard Git object model. Every squash, reorder, and reword it performs maps to an ordinary Git operation you could reproduce in a terminal. That means two things:

• Nothing Tower does is opaque or proprietary. git log --oneline and git reflog in a terminal will show you exactly what happened.
• Your CLI skills stay relevant, and you should keep them warm by occasionally inspecting what Tower actually did.

GUI abstractions can hide the plumbing. If you adopt Tower, make a habit of checking the reflog after history surgery — it doubles as a safety net and as continuing education.

Interactive rebase as a list you can drag

In Tower, interactive rebase presents your commits as a list where reorder, squash, fixup, edit, and reword are drag-and-drop or context-menu actions. Conflicts surface step by step with a diff view, rather than dumping you into raw conflict markers across multiple files.

A typical cleanup flow looks like this:

1. Check out your feature branch locally. Confirm it's yours alone — nobody else has pulled it.
2. In Tower's history view, select the commits back to the merge-base with main and start an interactive rebase.
3. Drag related WIP commits together and mark them squash or fixup; reword the survivors into meaningful messages.
4. Resolve any conflicts in the conflict view, one step at a time.
5. Verify in a terminal: git log --oneline origin/main..HEAD should show your tidy commit set.

The terminal check matters. It's your independent confirmation that the GUI did what you intended, and it takes ten seconds.

The undo is the real feature

Tower's headline capability is broad undo support — Cmd/Ctrl+Z works across many Git operations, including commits, branch deletions, and rebases. This changes the risk calculus for engineers who avoid history rewriting from the CLI because a mistake feels permanent.

You can test this yourself in a scratch repository: delete a branch in Tower, press Cmd/Ctrl+Z, then confirm restoration with git branch and git reflog. (Git itself almost never loses committed work — the reflog keeps orphaned commits reachable for weeks — but Tower's undo makes that safety discoverable instead of something you need to already know about.)

The engineering decision I'd argue for: use Tower to lower the barrier to local history hygiene. Squashing WIP commits before a pull request is low-risk, high-value work, and a tool that makes people actually do it beats a perfect CLI workflow nobody uses.

Where the convenience ends: shared history

Undo and drag-and-drop do nothing about the real hazard of rebasing: once commits are pushed and pulled by teammates, rewriting them forces everyone else to reconcile diverged history. Tower will surface the push rejection and offer a force-push prompt after a rebase — that prompt is a warning, not an invitation.

Practical policy:

• Rebase freely on branches only you have pulled.
• Coordinate explicitly before force-pushing anything shared; prefer --force-with-lease semantics so you don't clobber a teammate's newer push.
• Enforce shared-branch rules server-side (protected branches on GitHub, GitLab, Bitbucket, or Azure DevOps — all of which Tower integrates with for cloning and pull requests, though integration depth varies by provider and version). GUI convenience is not a substitute for server-enforced policy.

Limitations worth knowing before rollout

Tower is paid subscription software; pricing and licensing terms change, so confirm current terms before recommending team-wide adoption. UI details and feature availability also differ between the macOS and Windows builds and across major versions — verify against the version you actually install rather than trusting screenshots, including the ones in this post's general description. And for genuinely hairy three-way merges, the conflict view helps, but understanding Git's stage model still pays off.

Try it this week

Install a trial, create a scratch repo with five messy commits, and run the cleanup flow above. Then do the two verification passes: git log --oneline to confirm the rewritten history, and a delete-branch-then-undo to see the safety net work. If your team ships cleaner pull requests because the scary part got less scary, that's the whole argument.