Intent-Based Resolution Always prioritize understanding the intent behind changes rather than just looking at the code differences. Commit messages, PR descriptions, and issue references provide crucial context. Code changes have purpose - bugfixes should be preserved, features should be integrated properly, and refactors should maintain consistency. Conflict between a bugfix and a refactor Apply the bugfix logic within the refactored structure Simply choose one side without considering both intents Preserve All Valuable Changes When possible, combine non-conflicting changes from both sides rather than discarding one side entirely. Both sides of a conflict often contain valuable changes that can coexist if properly integrated. Escape Conflict Markers When using apply_diff or search_and_replace tools, always escape merge conflict markers with backslashes to prevent parsing errors. Consider Related Changes Look beyond the immediate conflict to understand related changes in tests, documentation, or dependent code. A change might seem isolated but could be part of a larger feature or fix that spans multiple files. Bugfixes generally take precedence over features Bugfixes address existing problems and should be preserved, while features can be reintegrated around the fix. More recent changes are often more relevant Recent changes likely reflect the current understanding of requirements and may supersede older implementations. When older changes are bugfixes or security patches that haven't been addressed in newer code. Changes that include test updates are likely more complete Developers who update tests alongside code changes demonstrate thoroughness and understanding of the impact. Logic changes take precedence over formatting changes Formatting can be reapplied, but logic changes represent functional improvements or fixes. Blindly choosing one side without analysis You might lose important changes or introduce regressions Always analyze both sides using git blame and commit history Ignoring the PR description and context The PR description often explains the why behind changes, which is crucial for proper resolution Always fetch and read the PR information before resolving Not validating the resolved code Merged code might be syntactically incorrect or introduce logical errors Always check for syntax errors and review the final diff Not escaping conflict markers in diffs Unescaped conflict markers (<<<<<<, =======, >>>>>>) in SEARCH or REPLACE sections will be interpreted as actual diff syntax, causing the apply_diff tool to fail or produce incorrect results Always escape conflict markers with a backslash (\) when they appear in the content you're searching for or replacing. Example: \<<<<<<< HEAD instead of <<<<<<< HEAD Fetch PR title and description for context Identify all files with conflicts Understand the overall change being merged Run git blame on conflicting sections Read commit messages for intent Consider if changes can be combined Escape conflict markers in diffs Verify no conflict markers remain Check for syntax/compilation errors Review the complete diff Document resolution decisions