When Git cannot combine two branches automatically, it pauses and leaves the competing changes for you to reconcile. On a Mac, use git status to find the affected files, compare both versions, edit each conflict into a deliberate combined result, then stage and finish the merge. The key is to preserve the intent of both changes, not blindly accept one side or assume that keeping both blocks will produce working code.

Confirm the operation and protect unfinished edits

Open Terminal or your editor’s integrated terminal, move to the repository, and check its state:

cd "/path/to/repository"
git status

Use the actual folder path in place of the example. Git’s status tells you which files are unmerged and whether the operation is a merge, rebase, or another action. This article covers a merge. For an ordinary merge, Git leaves the current branch in place while it waits for you to resolve conflicts; paths that merged cleanly are already updated, while conflicting paths need review. Git’s git merge documentation

If you have uncommitted work from before the merge, take care not to overwrite it while editing. Git documents git merge --abort as a way to stop a merge, but notes that it may not always reconstruct pre-existing uncommitted changes. If the state is unclear, save a separate copy of important local edits before continuing. Abort only when you intend to stop the merge, and inspect the resulting status afterward. Git’s merge conflict instructions

Read each conflict as two proposals

Open each listed file in a text editor. A text conflict is commonly marked like this:

<<<<<<< HEAD
current branch version
=======
incoming branch version
>>>>>>> branch-name

The text above ======= is generally the current branch’s version; the text below it is generally the branch being merged. The labels may vary. Git records the common ancestor and both branch versions in the index, and the working file shows a conflict-marked result for you to edit. Git’s merge documentation

Treat the two sections as evidence of the intended changes, not as choices you must accept whole. Ask what each edit was trying to achieve. One side may add a validation condition while the other changes a field name; preserving both may mean combining them into one updated condition. For a file-level conflict, such as one side deleting a file while the other edits it, decide whether the file should remain, and if so incorporate the needed edits. If the intent is not apparent from the lines, inspect nearby code or ask the change’s author before deciding.

Remove all conflict markers and write a coherent final version. Do not simply leave both blocks in sequence unless that is what the program or document should contain. Keeping both can duplicate declarations, overwrite behavior, or create invalid syntax. Conversely, choosing only one block can discard the other branch’s useful work. The correct resolution depends on the surrounding file and the purpose of each change.

Review and stage resolved files

Save the edited file, then inspect the changes. For a conflicted file, git diff shows the conflict-resolution work still present in your working tree. Check the full surrounding context, not just the marked lines. Search for leftover markers with your editor’s search function, or use this command in the repository:

git grep -n -E '^(<<<<<<<|=======|>>>>>>>)'

If it finds matches, review them: legitimate documentation or test fixtures can contain these strings, so do not delete matches indiscriminately. Once a file’s result is right, stage it by giving git add its quoted path, for example git add "Sources/Example.swift". Staging tells Git that the file’s conflict has been resolved; it does not prove the result is correct. Git’s instructions are to edit each conflict, add the resolved paths, and then commit or continue the merge. Git merge documentation

For a visual workflow on Mac, Visual Studio Code lists conflicted files under Merge Changes in Source Control. Open a file and use its inline conflict actions or Open in Merge Editor to inspect the current side, incoming side, and result. The editor’s Accept Both Changes action keeps both sections in sequence; review the resulting file and combine or adjust the content when needed. Save the result and stage the file in Source Control. These controls belong to VS Code; other editors may use different labels or features. VS Code’s merge conflict guide

Finish the merge and verify the outcome

After resolving and staging every conflicted file, check the state again:

git status
git diff --cached

Review the staged diff to ensure both intended contributions appear in a sensible final form and unrelated edits are not included. Run the project’s relevant checks if available; Git cannot determine whether the combined logic behaves as intended.

For a command-line merge, complete the operation with git merge --continue (or commit the merge when Git directs you to do so). Git’s --continue checks that a merge is in progress before creating the commit. Then run git status again to confirm the merge is no longer in progress. If Git reports more conflicts, resolve and stage those files too. Git’s merge instructions

A conflict is resolved safely when the final file deliberately accounts for both branches’ intended work, the staged diff matches that result, and the merge has completed. When you cannot determine what one side was meant to accomplish, pause and get that context before discarding or rewriting it.

Sources