| UI or UX | UI + UX - Source-code branch conflict resolver with file and hunk decisions | UI + UX - Guided workflow for reviewing and committing conflict decisions | UI + UX - Competing-version resolution state | UI + UX - Final editable answer summary before committing a transaction |
| UI guidance | Show the merge target, source branch, base branch, file path, conflict count, and current hunk before any Use ours, Use theirs, or Edit resolution action. | Show a durable resolution workspace that lists every unresolved conflict, exposes the current conflict, names each version source, and separates choose-local, choose-remote, merge, save-copy, skip, and commit actions. | Show both competing versions near the affected object, field, paragraph, file, row, or branch with source labels such as Your edit, Server version, Mina's edit, Target branch, and Current published value. | Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action. |
| UX guidance | Guide developers through file and hunk decisions, preserve both branch versions until commit, validate the resolved file for remaining markers, and route unsupported or risky files to local/manual resolution instead of pretending the browser can solve them. | Use conflict resolution after conflict detection when users must make one or more explicit decisions before a record, document, branch, import, or synced object can continue. | Preserve each version, explain why automatic merge was unsafe, guide users through the smallest conflicting unit, and make the post-resolution result reviewable before committing. | Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed. |
| Good UI | A merge request resolver shows Target main and Source feature/billing beside src/billing/rules.ts, lists 2 unresolved hunks, labels Use target and Use source controls, previews the resolved file, and keeps Commit resolution disabled until all conflict markers are gone. | A field report resolver shows 2 of 3 conflicts remaining, displays Your offline value and Mina's server value for the current field, offers Keep local, Keep server, Merge both, Save copy, and shows a reviewed result before Commit resolutions. | A field report says Conflict on supervisor comment, shows Your offline edit from 11:06 beside Server edit by Mina at 11:07, and offers Keep mine, Keep server, and Merge comment. | A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address. |
| Bad UI | A resolver lets users commit while <<<<<<< markers remain in the file. | A resolver lets users click Commit while some conflicts are still unresolved and hides which side will be lost. | A save banner says Something went wrong and only offers Retry after another user changed the same field. | Change links lack context, so assistive technology users hear a list of identical Change links. |
| Good UX | A developer opens a merge request conflict, chooses target for the dependency version, edits the feature flag block to keep both checks, reviews the resolved file, enters a commit message, and commits after validation passes. | A user resolves the supervisor comment by merging both versions, keeps the server contact number, saves the local safety note as a copy, reviews the final report, then commits with an audit summary. | A user tries to sync an offline field report, reviews only the two changed fields, merges one comment, keeps the server contact number, and commits a resolved version. | A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved. |
| Bad UX | A browser resolver removes conflict markers but produces syntax-invalid code and still enables Commit. | The system silently resolves all conflicts by newest timestamp and only shows a success toast. | The app silently keeps the newest server value and deletes the user's local note. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. |
| Best fit | A pull request, merge request, rebase, merge, or branch update has source-code conflicts that require developer decisions. | A conflict has been detected and a user must choose, merge, save-copy, skip, or commit a result. | Concurrent users, devices, branches, or background jobs changed the same object or location. | A user has provided multiple answers and should verify them before a consequential submit action. |
| Avoid when | The UI only needs to announce that a merge conflict exists and link to a resolver. | The interface only needs to signal that a conflict exists and route users elsewhere. | The user is managing an unpublished draft lifecycle rather than resolving competing edits. | The task is a single low-risk field with clear inline validation and an obvious submit action. |
| Required state | Repository and branch context state with target branch, source branch, and merge request or pull request identifier. | Conflict list state with unresolved count and current conflict position. | Conflict detected state naming affected object and source versions. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. |
| Accessibility burden | Use headings for repository, file, and hunk sections so keyboard and screen reader users can navigate conflict scope. | Place resolution controls after the compared values they affect and label them with the source they keep or discard. | Associate each conflict message with the affected field, row, line, paragraph, or file. | Use headings that make the review task explicit, such as Check your answers before sending your application. |
| Common misuse | Leaving Ours and Theirs undefined in a browser context where repository roles can invert by operation. | Marking conflicts resolved before the user reviews the surviving value. | Treating a conflict as a simple retryable save error. | Labelling the final commit button Continue. |