Squashing Commits Visually with Tower 4’s Interactive Rebase

The problem: a noisy commit history before a pull request

When working on a feature branch, it’s common to accumulate several small commits — ​for example, “Add file A”, “Update file A”, and “Fix typo”. ​Before opening a pull request, many teams prefer a cleaner history with fewer, more meaningful commits. ​Doing this manually with the command line requires remembering the exact git rebase -i syntax, which can be error‑prone, especially for developers who spend most of their time in a GUI.

Thesis: Tower 4’s visual interactive rebase lets you squash commits with drag‑and‑drop, reducing syntax mistakes

Tower 4 provides an Interactive Rebase window that displays each commit as a row. ​You can reorder, edit, or squash commits by dragging one row onto another and choosing an action from a context menu. ​Because the operation is performed through the GUI, you avoid typing the pick, squash, or fixup commands directly, which lowers the chance of a typo that would abort the rebase.

Understanding the UI elements

• Commit list: each line shows the abbreviated hash and commit message.
• Drag handle: a grippy area on the left of a row that you click and hold to move the commit.
• Squash option: when you drop a commit onto another, a popup lets you choose “squash” (keep both messages) or “fixup” (discard the dropped message).
• Result log: after finishing the rebase, Tower updates the branch’s commit graph so you can see the new, condensed history.

Worked example: squashing two commits in a test branch

Follow these steps in your local repository. ​No special permissions are required beyond normal read/write access to the repo.

1. Create a branch with three dummy commits:

   git checkout -b feature/squash-demo
   # Commit 1
    echo "initial" > file.txt
    git add file.txt
    git commit -m "Add file A"
   # Commit 2
    echo "more" >> file.txt
    git add file.txt
    git commit -m "Update file A"
   # Commit 3
    echo "# typo fix" >> file.txt
    git add file.txt
    git commit -m "Fix typo"
   

2. Open Interactive Rebase in Tower:
   • In the Tower sidebar, right‑click the feature/squash-demo branch.
   • Select Interactive Rebase from the context menu.
   • A window appears listing the three commits in chronological order.
3. Squash the second commit into the first:
   • Click and hold the drag handle on the row for "Update file A".
   • Drag it onto the row for "Add file A".
   • When prompted, choose Squash.
   • An edit box opens allowing you to refine the combined commit message; you might change it to "Add and update file A".
   • Leave the third commit ("Fix typo") unchanged.
4. Finish the rebase:
   • Click the Start button (or equivalent) in the Interactive Rebase window.
   • Tower will apply the changes using the underlying Git binary.

Verifying the result

After the rebase completes, you can check that the history now contains two commits:

git log --oneline feature/squash-demo

You should see output similar to:

a1b2c3d Add and update file A
 e4f5g6h Fix typo

The original three‑commit chain has been collapsed into a single squashed commit plus the untouched "Fix typo" commit.

Trade‑off and limitation

While the visual rebase is convenient, it relies on the local Git executable that Tower invokes. ​If your system runs an outdated Git version, some rebase options (e.g., --rebase-merges) may behave differently or be unavailable. ​Additionally, Tower draws the entire commit graph to enable the drag‑and‑drop interface; in repositories with hundreds of thousands of commits, this can cause noticeable lag or memory usage spikes. ​A practical mitigation is to filter the history (e.g., by branch or date range) before opening Interactive Rebase, or to perform very large rebases directly on the command line where you can limit the walk with --since or --max-count.

Another consideration is that rebasing rewrites history. ​If the branch you are rebasing has already been pushed and shared with teammates, force‑pushing the rewritten history can disrupt their work. ​Always ensure the branch is either private or that you have coordinated with collaborators before pushing a rebased branch.

Actionable closing

For small to medium‑sized repositories, Tower 4’s Interactive Rebase offers a low‑friction way to tidy up commit histories without memorizing rebase syntax. ​Try the workflow described above on a throwaway branch, verify the outcome with git log, and adopt it as part of your pre‑pull‑request cleanup routine—​just remember to keep your local Git up to date and to avoid rebasing shared branches unless you’ve communicated the change.