| 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 | Use a merge conflict resolver when a source-control merge, rebase, pull request, or merge request cannot continue until developers decide which code survives in one or more conflicted hunks. | 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. | Use conflict state when multiple valid changes overlap and the system needs a human, rule, or review workflow to decide what survives without losing work silently. | 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 merge screen has Accept all incoming with no target/source branch labels, file paths, or discarded code preview. | A conflict page has one Accept recommended button for all fields and no way to inspect discarded values. | A save banner says Something went wrong and only offers Retry after another user changed the same field. | A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or 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 | The tool resolves conflicts by newest commit timestamp and merges without showing the lost branch code. | 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 conflict is a non-code record, document, import row, or form value without repository branch semantics. | The system can safely merge non-overlapping changes without user judgment. | Only one operation failed and there is no competing valid version. | 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. | No conflict state after automatic safe merge. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. |
| Accessibility burden | Expose branch names, file paths, hunk numbers, line labels, and resolution status as text, not only color or diff markers. | Expose conflict number, total count, source labels, field names, and resolution status as text, not only color or diff markers. | Use headings and text labels to name each side of the conflict; do not rely only on red/green diff colors. | Use headings that make the review task explicit, such as Check your answers before sending your application. |
| Common misuse | Using Accept all incoming without showing file paths, branches, or discarded code. | Marking conflicts resolved before the user reviews the surviving value. | Treating a conflict as a simple retryable save error. | Using a review page that contains no captured answers. |