Resolving merge conflicts on the Mac without the terminal

What a merge conflict really is

A merge conflict happens when Git has to combine two changes that touch the same part of a file. As long as two branches work on different lines, Git merges them without asking. As soon as the changes overlap, Git cannot decide which version should win, so it asks you. This is not an error and not a sign that something broke. It is the normal moment where Git honestly says that a human decision is needed here.

Conflicts typically show up when you merge a branch, rebase, or apply a stash. In every case the mechanism is the same, and in every case your project stays in a safe, well defined intermediate state until you have resolved the conflict.

Why the terminal often triggers panic

On the command line, Git reports a conflict with a terse line and leaves the rest to you. You do not immediately see which files are affected, how the two versions look side by side, or what a safe next step would be. In exactly that moment many developers frantically search for commands, paste something they do not fully understand, and make the state worse.

Yet the conflict itself is harmless. What is missing is an overview. A graphical Git client shows you the same information calmly and legibly, and that is what takes the stress out.

Reading the conflict markers

When a conflict occurs, Git writes special markers into the affected file:

<<<<<<< HEAD
your current version (ours)
=======
the version from the other branch (theirs)
>>>>>>> feature/login

The top block between the angle brackets and the divider is ours, the state of the branch you are currently on (HEAD). The bottom block is theirs, the state you are bringing in. Resolving means deciding which lines stay, removing the markers, and bringing the file into the intended final state. That can be one of the two sides, a mix of both, or something entirely new.

Resolving a conflict step by step

1. First get an overview of which files are affected at all. A good client lists them as their own group so you do not miss any.
2. Open the first file and read both sides. Do not immediately ask which one wins, ask what the correct final state is.
3. Decide per conflict block. Sometimes ours is right, sometimes theirs, and often you need parts of both.
4. Remove the markers and keep only the intended code. Not a single one of the angle bracket characters may remain.
5. Save, mark the file as resolved, and repeat for every other conflicting file.
6. Once all files are resolved, finish the merge with a commit. During a rebase the step is called continue instead of commit, but the logic stays the same.

ours or theirs? Making the call

The most common question is which side should win. There is no blanket answer, but a good rule of thumb is to decide by intent, not by origin. Ask what behaviour the code should have in the end, and choose the lines that produce that behaviour. If both sides contribute important parts, the right resolution is almost always a deliberate combination.

A frequent mistake is to blindly take one side in full just to get rid of the conflict quickly. That is how you lose changes someone else made on purpose. Take the half minute and read both versions.

How Spire helps

Spire is a native Git client for the Mac, built with SwiftUI and AppKit. On a conflict you get the affected files as a clear list and see the two sides side by side in a structured way, instead of hunting for raw markers in a text file. You mark resolved files with a click, and Spire keeps the merge state clean until you are done. Because Spire ships its own Git, this works even when there is no Git installed on the machine at all.

Important and honest: a tool does not make the content decision for you. What it removes is the searching, the fear of the wrong command, and the worry that you will destroy the state. That is exactly the difference between panic and routine.

Check, then commit

Before you make the closing commit, take a look at the overall result. Does the project still build? Do the tests pass? A conflict is only truly resolved when the result works, not already when the markers are gone. Feel free to note briefly in the commit message which decision you made, so later readers understand the context.

Short checklist

• A conflict is normal, not damage.
• ours is your current branch, theirs is coming in.
• Decide by intent, not by origin.
• Remove every marker completely.
• Verify it works, then finish.