Resolve Git Merge Conflicts by Understanding Both Changes

A practical approach

Step 1

Before resolving, read the commits on both sides that touched the file, using git log -p or your hosting platform, to understand each intent.

Step 2

Enable the diff3 or zdiff3 conflict style with git config merge.conflictStyle zdiff3, which also shows the original common ancestor and makes intentions clearer.

Step 3

Write the combined result, remove all conflict markers and keep formatting consistent.

Step 4

Run the build and tests before completing the merge or rebase.

Step 5

If a conflict is large or the intent unclear, talk to the author of the other change before guessing.

Worked example

Two developers change the same pricing function: one adds a student discount, the other changes rounding to two decimals. Resolving by accepting the incoming side keeps the rounding but silently drops the discount. Reading both commits and writing a function that applies the discount and then rounds keeps both behaviours, and the tests for each confirm it.

A mistake to avoid

Do not search only for the first conflict marker and stop. Files can contain several conflicts, and leftover markers will break the build or, worse, end up in text content.

Try it yourself

In a practice repository, create two branches that change the same function in different ways and merge them. Resolve the conflict with zdiff3 enabled and write a test that checks both changes survived.

Your implementation checklist

• I read both sides' commits before resolving
• zdiff3 or diff3 conflict style is enabled
• The resolution combines both intents
• No conflict markers remain
• Build and tests pass before completing the merge