Resolving Git Merge Conflicts Without Leaving Tower

Merge conflicts are where a lot of Git workflows fall apart. You're mid-merge, Git dumps conflict markers into a file, and suddenly you're juggling a terminal, an editor, and a mental model of what "ours" and "theirs" meant three branches ago. Tower, the Git GUI for macOS and Windows, handles this moment better than most clients: since version 3.0 it ships an integrated conflict-resolution view that lets you inspect, edit, stage, and commit a resolution without leaving the app.

The thesis here is simple: for text-file conflicts, Tower's built-in resolver is usually faster and less error-prone than hand-editing conflict markers — but it has real limits, and knowing where they are saves you from a bad merge.

What the conflict view actually shows you

When a merge or rebase produces a conflict, Tower flags the affected files in the working-copy view. Opening one launches a three-panel layout: the common ancestor (base), the incoming changes, and your current changes, with a syntax-highlighted diff so you can see exactly where the two sides diverged.

That base panel matters more than people expect. Conflict markers in a raw file only show you the two competing versions; seeing what the file looked like before either side touched it often makes the correct resolution obvious. If both sides added different logic around the same original line, the base tells you what that line was doing.

Resolving line by line, then committing in place

For each conflicting hunk you can accept the current side, accept the incoming side, or — the useful case — edit the merged result directly using the in-place editing toolbar. This is the right move when neither side is wholly correct, which in practice is most non-trivial conflicts.

Once every hunk is addressed, clicking Resolve stages the file immediately. You can then create the merge commit from the same window. The whole loop — inspect, decide, edit, stage, commit — stays inside one UI, which removes the classic mistake of forgetting to git add a resolved file and committing a half-finished merge.

A worked example you can verify yourself

You can exercise the entire flow in a throwaway repository. Run these in any terminal (no special permissions needed; replace paths as you like):

mkdir tower-conflict-demo && cd tower-conflict-demo
git init
printf 'line one\nline two\nline three\n' > notes.txt
git add notes.txt && git commit -m "base"
git checkout -b feature
sed -i '' 's/line two/feature change/' notes.txt   # on Windows/Git Bash: sed -i 's/.../.../' notes.txt
git commit -am "feature edit"
git checkout main
sed -i '' 's/line two/main change/' notes.txt
git commit -am "main edit"
git merge feature   # expect: CONFLICT in notes.txt

Now open the repository in Tower (version 3.0 or later). The conflicted file appears in the working-copy view; open it and confirm the three-panel conflict view appears with main change and feature change as the competing sides. Pick one side, or edit the result line to combine both, then click Resolve.

Two checks confirm it worked: the file should show as staged in Tower (no conflict marker remaining), and after committing from the same window, git log -1 --format=%P in your terminal should show two parent hashes — a real merge commit. Running git status should report a clean tree. If the file still contains <<<<<<< markers, the resolution wasn't applied; reopen the conflict view.

Where the feature stops helping

The resolver only handles text-based files: source code, configs, markup. Binary conflicts — images, compiled artifacts, design files — are delegated to whatever external merge tool you've configured in Tower's preferences, which may mean extra setup or, honestly, a manual decision about which version to keep.

There are also scale limits. With many simultaneous conflicts, the three-panel view gets crowded, and very large files (on the order of 10 MB and up) can make the view sluggish. If you're staring down a generated file or a giant lockfile conflict, regenerating the file and staging the result is usually the saner path:

git checkout --theirs package-lock.json   # or regenerate it, then:
git add package-lock.json

One more caveat: Tower stages the file the moment you click Resolve. That's convenient, but it means "resolved" and "correct" are not the same thing — the UI can't tell whether your merged logic compiles or passes tests.

The practical takeaway

Use Tower's conflict view for what it's good at: text conflicts where you need to see base, current, and incoming side by side and commit the fix without context-switching. For binaries, huge files, or conflicts where the right answer is "regenerate it," fall back to the command line or an external tool. Either way, before you commit the merge, run your test suite — a clean three-way merge is no guarantee of working code.