It can genuinely help resolve a conflict — but what you hand over and what you check before accepting matters more than the resolution itself.
Hand over the real conflict markers (<<<<<<<, =======, >>>>>>>) and explain what each side was trying to do, not just a resolved file. Resolving it yourself first removes the exact context that's actually useful.
A resolution can be syntactically valid — it compiles, it runs — while still being semantically wrong, silently dropping one side's real intent. For simple, non-overlapping conflicts this is rarely an issue; for conflicts where both sides changed logic for a real reason, review it as carefully as you'd review any other change. See reading your first diff for the habit this depends on.
If you genuinely don't know why the conflicting branch made its change, say so explicitly rather than letting a resolution get picked silently — that missing context is exactly the kind of thing worth surfacing rather than guessing past.
The free guide covers reading a diff carefully — the exact habit this depends on.
Get the Free Guide →For simple, non-overlapping conflicts, usually. For conflicts touching logic both sides changed for a real reason, review the resolution as carefully as you'd review any other diff — the risk is picking a resolution that's syntactically valid but semantically wrong.
Say so explicitly rather than letting a resolution get picked silently — the real intent behind a conflicting change is exactly the kind of context that isn't visible in the diff alone.
Hand over the actual conflict markers and context rather than resolving it yourself first — that's the part it can actually help with.