Cleaner Pull Requests with Tower Git's Visual Interactive Rebase

A feature branch with "fix typo", "WIP", "actually fix it" and three reverts is a review tax. The actual problem is not the code, it is the story the history tells. A practical engineering decision is to clean the local history before a pull request is shared, and to do it in a way that is auditable and reversible.

Tower Git's visual interactive rebase is a supported way to do that without memorizing rebase todo syntax. The thesis is simple: make history cleanup a deliberate, visible operation with clear scope, so teams get linear, readable PRs without increasing the risk of accidental history loss.

Why visual rebase changes the decision

Interactive rebase rewrites commits. Git creates new SHA-1 hashes for every rewritten commit and leaves untouched commits with their original hashes. That property matters for safety: a limited range rewrite touches only what you select.

Tower exposes this as a drag-and-drop list in the history view. You select a range of commits on a local branch, choose Rebase interactively, and you get a dialog where each commit can be pick, squash, fixup, edit, or drop. Reordering is drag-and-drop. The UI shows the resulting parent chain before you apply.

For teams, this supports a policy of "rebase feature branches before merge". The visual list makes the intent explicit for reviewers and reduces the chance of an accidental edit to the wrong commit.

Worked example: squash WIP commits before review

Assume a local branch feature/login with three recent commits on top of main:

• add login form
• WIP: adjust validation
• fix validation edge case

In Tower, open the repository, switch to feature/login, and select the two WIP commits in the history view. Open the context menu and choose Rebase interactively.

In the dialog, change the action for "WIP: adjust validation" to squash and keep "fix validation edge case" as pick. Drag to ensure the desired order. The dialog shows a preview of the new commit message, which will combine the messages of the squashed commits.

Apply the rebase. Tower will rewrite only the selected range. Commits below the range keep their original SHA-1 hashes. The branch now has two commits instead of three, with a combined message that explains the validation change.

To verify the result locally, check the history view for the reduced commit count and the merged message. If the branch is private, you can push the rewrite with:

git push --force-with-lease origin feature/login

Run this in a terminal at the repository root with write permission to the remote. --force-with-lease fails if someone else updated the remote ref, which is the safety check against overwriting teammates. The expected check is that the remote branch now points to the new tip and the commit count matches the local view. The risk is history rewrite: anyone who has already pulled the old commits will have divergent history.

Trade-offs and limits

Interactive rebase must only be used on branches that have not been pushed to a shared repository, or where force-push is explicitly allowed by team policy. Rewriting public history can break collaborators' clones.

Tower's built-in conflict resolver works per file inside the GUI and is sufficient for typical text conflicts. It may not handle complex binary merges as smoothly as a dedicated merge tool. If a conflict arises during the visual rebase, resolve each file in Tower, mark resolved, and continue the rebase from the dialog.

Unchanged commits preserve their SHA-1, which limits blast radius, but any commit that is moved, squashed, or dropped is rewritten. Keep a backup branch before a large rewrite, e.g. git branch feature/login-backup, so you can reset if needed.

Use visual rebase as a pre-review hygiene step, not as a post-merge cleanup tool. The actionable rule: clean locally, review linearly, merge once. That keeps PR discussion focused on intent rather than on commit noise.