Git Merge Conflict Resolution Guide

What this prompt does

This prompt helps you resolve a real merge conflict when merging [source_branch] into [target_branch] in a [language] project. You give it the [file_count], the [conflict_area], and the actual [conflict_diff], and it explains what each side of the conflict is trying to achieve before recommending a resolution strategy. It then provides the resolved code with explanations, a testing checklist to verify the merge, and .gitattributes or merge-driver configs to prevent the same conflict recurring.

The structure works because it treats a conflict as two competing intentions to reconcile, not a binary "accept theirs or ours" choice. That framing matters most in areas like database migrations and API controllers, where both sides usually carry real intent that must be preserved. By also producing a pre-merge checklist for the team, the prompt turns a one-off rescue into a habit that reduces future collisions. The testing checklist it generates is scoped to the [conflict_area], so if the conflict lives in migrations you get migration-specific verification rather than generic "run the tests" advice. That matters because a wrong merge in schema files can corrupt state in ways unit tests for unrelated features will happily pass right over.

When to use it

• You are stuck on a conflict merging [source_branch] into [target_branch] and want to understand both sides.
• The conflict spans [file_count] files in a sensitive [conflict_area] like migrations or controllers.
• You are unsure whether to accept theirs, accept ours, or merge manually.
• You want a testing checklist to confirm the merge did not silently break behavior.
• The same files keep colliding and you need .gitattributes or merge-driver rules to stop it.
• You want a reusable pre-merge checklist to share with your team.

Example output

Expect a guided resolution: an explanation of each side's intent, a recommended strategy (accept theirs, accept ours, or manual merge) with reasoning, the resolved code annotated so you understand each decision, and a testing checklist scoped to the [conflict_area]. It usually closes with suggested .gitattributes or merge-driver configuration and a team pre-merge checklist aimed at preventing the same [conflict_diff] pattern again.

Pro tips

• Paste the full [conflict_diff] with surrounding context; the resolution quality depends heavily on the model seeing both sides clearly.
• Name the [conflict_area] precisely, because conflicts in migrations need different care than conflicts in pure presentation code.
• Do not blindly accept either side on [file_count] files at once; let the prompt reconcile intent file by file where it matters.
• Run the generated testing checklist before pushing, especially when migrations are involved, since a wrong merge can corrupt schema state.
• Apply the suggested .gitattributes rules so recurring collisions in the same files stop happening.
• Iterate by feeding back any test failures after the merge and asking it to adjust the resolution.