Choosing Merge Strategy in Tower: Merge Commit vs Rebase vs Squash

The problem is a finished feature branch in Tower and no clear rule for how it should land on main. The useful takeaway is to pick the integration method from the constraints first — shared branch, auditability, and whether you need a linear log — then execute in Tower and verify the topology before pushing.

Decision constraints before you merge

Three constraints drive the choice in Tower for macOS and Windows.

• History policy. Does the team require a linear log or preserve branch topology?
• Auditability. Do you need per-commit messages and authors retained for review or compliance?
• Branch sharing. Have the commits been pushed and pulled by others? If yes, rewriting history is unsafe.

Rebase and squash rewrite commit hashes. That is safe only on local-only branches. Standard merge preserves hashes.

Options compared

Trade-offs by workflow

Standard merge in Tower is the safest default for shared work. Drag the feature branch onto the target in the sidebar or use the Merge toolbar button. It keeps every commit intact and is easy to revert. The cost is a branching graph.

Rebase in Tower, via drag-and-drop with Rebase chosen or the branch context menu, gives a linear history. It is useful when the team values a clean log and the branch has not left your machine. Never rebase commits already pushed and pulled by teammates because the new hashes diverge from the remote.

Squash merge keeps main terse by collapsing the feature into a single commit. It suits a small, finished change. It loses per-commit detail, so avoid it for long-running work. If you squash, delete or recreate the feature branch afterward; continuing to develop on it creates duplicate changes later.

Tower provides undo for many Git operations, including merges and rebases, via Cmd/Ctrl+Z. That lowers the risk of experimenting, but undo coverage varies by version and platform. Confirm against your installed version before relying on it.

Concrete execution in Tower

Example context: local repository checked out at /path/to/repo, feature branch feature/login, target main. You need write access to the local repo; pushing requires remote write permission.

1. Open the repo in Tower and ensure you are on main with an up-to-date working tree.
2. In the sidebar, drag feature/login onto main. A menu appears with Merge, Rebase, Squash.
3. Choose the strategy matching the constraints above.
4. If conflicts appear, resolve them in Tower's conflict editor, mark resolved, and continue.
5. Before pushing, build and run tests locally to confirm the working tree is healthy.

Menu names and placement vary across Tower versions and platforms. Verify the exact labels in your build.

Validating the result

Inspect the target branch in Tower's History view.

• Merge commit shows two parents in the graph.
• Rebase shows a straight line with the feature commits now sitting on top of the target tip and new hashes.
• Squash shows one new commit on the target with the combined message.

Cross-check with a terminal in the repository folder:

git log --graph --oneline main

Expected checks: the graph matches the chosen strategy, no unexpected divergences, and the working tree is clean. Relevant risks: pushing a rewritten history will require force push and will disrupt teammates.

To test undo behavior safely, create a scratch repository, perform a merge, then use Tower's undo and verify via:

git reflog

Check that HEAD and branch refs returned to their prior state. Do not run this on shared work.

Limitations

Feature names and undo coverage vary by Tower version and OS. Squash merging a branch you intend to keep causes duplicate-change conflicts. Rebase and squash must not be used on commits already based on by others. Always confirm the History view and terminal log agree before pushing.