Using Tower’s Visual Merge Conflict Editor to Resolve Conflicts Without Leaving the GUI

The problem: context switching when conflicts arise

When a merge or rebase produces conflicting changes, developers often drop to the command line, run git mergetool or manually edit files, then return to the GUI to continue work. This back‑and‑forth interrupts flow and increases the chance of missing a resolution step.

Thesis: Tower’s built‑in visual conflict editor keeps the workflow inside the GUI

Tower Git client presents conflicting hunks side‑by‑side with the base, "ours" and "theirs" versions, allowing you to accept, edit, or reject changes directly in the same window where you view the commit graph. This design decision reduces context switching and makes the resolution steps visible as part of the history.

How the visual conflict editor works

When Tower detects a conflict, it opens a dedicated pane:

• Base – the common ancestor version.
• Ours – the current branch’s version.
• Theirs – the incoming branch’s version.

Each hunk shows checkboxes to choose a side, and a manual edit area where you can combine lines. Clicking “Apply” writes the resolved file, and Tower automatically stages the change.

Worked example: resolving a merge conflict

1. Start with two branches, feature/login and main, that have both edited src/auth.js.
2. In Tower, drag feature/login onto main and choose “Merge”. Tower reports a conflict and opens the conflict editor.
3. The editor shows three columns: Base (original logic), Ours (your new validation), Theirs (a refactor on main). For the conflicting hunk, you select “Ours” for the validation block and manually add a missing import from Theirs.
4. Press “Apply”. Tower stages src/auth.js and updates the merge commit preview.
5. Finally, click “Commit Merge” to finish.

All steps stay inside the Tower window; no terminal commands are needed.

Trade‑offs and limitations

The visual editor works best for textual conflicts that fit on the screen. Large binary files or complex refactorings that span many hunks may still require external merge tools. Additionally, the editor relies on Tower’s internal diff engine; if you need a specific external diff/merge program (e.g., for legal compliance), you must configure Tower’s preferences to fall back to it.

Actionable closing

Next time you encounter a merge or rebase conflict in Tower, try the built‑in editor before reaching for the command line. Verify the resolution by checking the staged changes in the “Changes” view and confirming the commit message reflects the merge. If the editor does not suit a particular file type, adjust the external merge tool setting under Preferences → Diff & Merge and repeat the workflow.