Merge conflict resolver

Problem Context

• A merge, rebase, pull request, or merge request detected overlapping edits in one or more files.
• The conflict is represented as code hunks, file versions, branch names, conflict markers, or repository metadata rather than ordinary form fields.
• Some conflicts can be resolved in a browser or desktop UI, while binary files, huge files, generated lockfiles, or complex rebases may require a command-line or IDE route.
• Committing the resolution changes repository history or merge request state and may trigger tests, review requirements, or branch protection.

Selection Rules

• Choose merge conflict resolver for source-control branch conflicts with files, hunks, target/source branch labels, conflict markers, and a resolution commit.
• Use conflict resolution for non-code records, documents, imports, or synced objects that need a general decision workflow without repository-specific semantics.
• Use conflict state when the interface only needs to tell users that competing versions exist and route them to a resolver.
• Use inline edit only for editing a value in place; a merge conflict resolver must preserve both branch versions and validate the entire resolved hunk or file.
• Use review-before-submit when users verify their own entered values before a transaction, not when two branches changed the same code.
• Resolve at the smallest source-control unit the developer can judge: hunk, file, generated artifact, rename, delete/modify conflict, or binary asset.
• Provide branch labels that match the repository vocabulary, such as target/source, base/head, main/feature, incoming/current, or ours/theirs with explicit definitions.
• Block commit while conflict markers remain, required files are unresolved, validation fails, unsupported files need local resolution, or the server rejects the new resolution commit.
• Show final commit scope, commit message, files changed, and unresolved count before creating the merge-resolution commit.
• After successful commit, refresh mergeability and preserve a visible audit trail in the merge request, branch history, or review discussion.

Required States

• Repository and branch context state with target branch, source branch, and merge request or pull request identifier.
• Conflict file list state with unresolved count and file paths.
• Current hunk compare state with source and target code labels.
• Use target or ours decision state.
• Use source or theirs decision state.
• Inline edit resolved hunk state.
• Validation failure state for remaining conflict markers, syntax errors, or unresolved hunks.
• Unsupported file or local-tool-required state.
• Review resolved files state with changed-file summary and commit message.
• Committed resolution state after the repository accepts the resolution commit.

Interaction Contract

• The resolver opens from a known merge conflict and keeps branch pair, file path, hunk number, and total unresolved count visible.
• Each hunk decision records whether target, source, or edited code survives and keeps both original branch versions available until the resolution commit succeeds.
• Next and Previous hunk controls preserve decisions and move focus to the next conflicted block.
• Inline editing validates that conflict markers are removed and required syntax or repository checks pass before commit is enabled.
• Unsupported files show explicit local or IDE instructions and do not count as resolved until the repository receives a valid resolution.
• The commit action includes the resolved file list and commit message and is disabled or intercepted when conflicts remain unresolved.
• After commit, the interface refreshes mergeability and reports if the target branch moved, branch protection blocks the commit, or CI/review gates still apply.
• The workflow exposes a way to reopen decisions, discard the attempted resolution, or continue locally when browser resolution is not appropriate.

Implementation Checklist

• Model conflicts as repository files with target branch value, source branch value, base context, hunk ranges, conflict markers, decision, resolved text, validation errors, and commit state.
• Use source-control terms consistently and define ours/theirs when those labels appear.
• Render code in monospace blocks with line context, changed-line highlighting, file path, branch labels, and accessible text for inserted, removed, target, and source code.
• Implement choose target, choose source, edit resolved hunk, reset hunk, next file, previous file, review files, open local instructions, and commit resolution controls.
• Detect remaining conflict markers such as <<<<<<<, =======, and >>>>>>> before enabling commit.
• Persist partial decisions through route changes, authentication refresh, target branch refresh, and browser reload when repository policy permits.
• Route binary files, oversized files, submodules, generated lockfiles, rename/delete conflicts, and protected-branch failures to a manual or local tool path.
• Test branch-label clarity, hunk navigation, marker validation, syntax validation, unsupported files, target branch moved, commit failure, keyboard access, screen reader labels, and audit trail output.

Common Generated-UI Mistakes

• Using Accept all incoming without showing file paths, branches, or discarded code.
• Leaving Ours and Theirs undefined in a browser context where repository roles can invert by operation.
• Enabling Commit while conflict markers remain.
• Treating a binary or generated file as editable text.
• Clearing the merge conflict badge before the repository accepts the resolution commit.
• Hiding branch-protection, moved-target, or CI blockers after the browser commit is created.
• Mixing general document conflict copy into a code resolver without hunk, file, branch, and commit semantics.

Critique Questions

• Can the developer tell which branch each side of the hunk comes from?
• Which file and hunk are being resolved, and how many remain?
• Can the developer inspect the code that will be discarded before committing?
• What prevents commit while conflict markers, unsupported files, or validation errors remain?
• How does the resolver handle target branch movement or server rejection after local-looking resolution?
• Where is the resolution commit message, audit trail, and merge request status shown?