How do I read Git conflict markers when two branches change the same lines?

Those lines bracket competing versions of part of the file. In Git’s usual textual conflict-marker style, the text after <<<<<<< is from the current side; the text after ======= is from the other side, and >>>>>>> closes that section. The markers help you locate the conflict, but they are not the intended final content. You must decide what the file should contain and edit it accordingly. [S1]

For example, suppose the conflicted file contains:

<<<<<<< current side
color = "blue"
=======
color = "green"
>>>>>>> other side

Assume the labels are placeholders and the two values are the competing edits. The resolved file might keep color = "blue", keep color = "green", or use a different result that combines the intended changes. The example does not tell you which choice is right; that depends on the project’s intended behavior.

For a typical merge, think of the first section as the current side and the second as the other side. Git’s merge documentation describes the current side as the current HEAD and the other side as the other branch’s MERGE_HEAD. But don’t rely on a casual reading of “mine” and “theirs” if you are unsure which operation or labels produced the conflict: side labels and marker style depend on merge context and configuration. [S1]

A merge can also have a common ancestor version recorded in the index. That base version is not shown in the usual two-section marker style. A diff3 or zdiff3 style can include a base section as well, which gives you another point of comparison. [S1] If you see extra markers, read the exact format in front of you rather than assuming every conflict has only two visible alternatives.

Compare each alternative with the surrounding code or text and the purpose of both edits. Ask: What was each change trying to accomplish? Can both goals be preserved in one final version? Does the surrounding content still make sense after the conflict is removed? If you cannot establish the intended result from the file and your project context, ask the relevant teammate or maintainer rather than guessing.

Continuing the illustrative example, suppose one side changes the default color and the other changes a label that is not shown in the snippet. If those edits affect separate lines, a sensible resolution might preserve both—but this small example does not establish that they are compatible. Inspect enough surrounding content to understand the actual change. Treat the sample as a reading aid, not a rule that one side wins.

Read the whole edited section as the file should look after the merge. Confirm that you made the intended choice or combination, that no conflict markers remain in the resolved section, and that the surrounding content is coherent. Then stage the resolved file; Git’s merge documentation describes editing the file to the intended final content, removing the markers, and staging the result. [S1] For example, a staged-file command might be git add path/to/file; replace the path with your actual file. Staging records the resolution for the merge, but it does not establish that your chosen content is behaviorally correct.

Annotated resolution

# Before: competing edits, not a finished result
<<<<<<< current side
color = "blue"
=======
color = "green"
>>>>>>> other side

# After: illustrative choice only
color = "blue"

The after-version is appropriate only if blue is the intended final value. If neither alternative is right on its own, edit the file to the intended combined result. The markers themselves do not decide what the code or content ought to be.