Git Conflict Resolver

Problem It Addresses

During collaborative work, git merge, git rebase, or PR integration can introduce <<<<<<<, =======, and >>>>>>> conflict markers. A developer needs to understand what the current branch changed, what the incoming branch changed, and which side should be kept. This skill focuses on the conflicted code itself: it explains the conflict, provides replacement-ready resolution code, and adds verification and prevention guidance.

How It Works

Use it by pasting a code snippet that includes conflict markers. It works through the following steps:

• Identify both sides: separates the current branch changes from the incoming branch changes.
• Analyze intent: decides whether the changes are alternate implementations of the same goal or parallel additions of different logic.
• Offer options: typically keep the current branch, keep the incoming branch, or merge both changes with a recommended implementation.
• Check consistency: flags syntax risks, possibly affected files, and tests to run after the merge.

The output aims to provide code that can replace the conflicted block directly, while explaining the impact of each option so the developer makes the final decision. It can also explain rebase, merge, and squash choices for different scenarios, but it does not run Git commands locally.

Boundaries And Notes

This skill is not a substitute for Git tutorials, branch strategy design, code review, or CI/CD setup. It depends on the context you provide; if the snippet is too short, the conflict depends on business decisions, or the intent of both sides is unclear, the developer must confirm the result. Binary file conflicts and large-scale code migrations should not be handled by text merge alone. Before pasting code, remove secrets, internal URLs, and other sensitive data, and run tests or manual verification after resolving the conflict.