Merge Conflicts

Merge Conflicts provides a repository-scoped workflow for merging branches, reviewing conflicted files, and pushing the resolved result.

Before starting

A merge writes commits and pushes a branch, so verify access and repository state first.

• The workspace repository must be reachable with credentials that can fetch and push the affected branch.
• The user needs View Merge Conflicts to inspect requests and Manage Merge Conflicts to start, edit, complete, skip AI, or cancel them.
• Multiple tickets can resolve conflicts for the same repository concurrently. Each request keeps its own files, review state, completion, failure, and cancellation outcome.
• Confirm branch protection permits the configured credential to update the target branch. For pull-request merges, the source branch must accept pushes.
• Treat AI-proposed changes as untrusted until reviewed and tested.

Start a merge

A merge request identifies one repository and two branches.

Entry	Result
Source and destination branch names	The resolved commit is pushed to the destination branch.
GitHub pull-request URL	Branches are read from the pull request and the resolution is pushed to its source branch.
Azure DevOps pull-request URL	Branches are read from the pull request and the resolution is pushed to its source branch.

If Git can merge cleanly, Polygent commits and pushes the result without opening the conflict editor. A temporary session-host disconnect during repository setup is recovered automatically without failing the merge request; review the destination branch or existing pull request after completion.

Resolve conflicted files

The conflict workflow combines optional AI assistance with mandatory human review.

1. Wait for the automated attempt, or select Skip AI to proceed manually. Assigned developers see the ticket in sidebar My Work during conflict resolution.
2. Review every file under Conflict Files in the diff editor.
3. Edit the resolved side to the required final content.
4. For a binary conflict, choose either Source or Destination; binary files cannot be edited in the browser.
5. Mark each file resolved and complete the merge.
6. Confirm the push succeeded, then run the repository's normal build, test, and security checks.

The file list shows the conflicted files only. Files Git merged on its own are not listed and need no action. Every conflicted file requires your review before completing.

The comparison uses the destination branch state captured when the merge began as its baseline. When you complete the resolution, Polygent fetches the latest remote branch state before pushing. Confirmed new conflicts return the request to conflict review while preserving your committed resolution; fetch failures, conflict-inspection failures, and merge failures without confirmed conflicts stop the request with distinct diagnostics in system logs.

Hooks and validation

Merge work can run configured session hooks at initialization, after AI work, on completion, and on cancellation.

Use hooks for non-interactive validation such as dependency checks or a test suite. A hook is not a substitute for branch protection or pull-request checks; keep required checks enforced by the Git provider. See Session Hooks.

Cancel safely

Selecting Cancel Merge opens a confirmation warning that current resolution work will be lost. The merge remains unchanged if you close the confirmation. Confirming stops in-progress assistance, removes the temporary merge workspace, and marks the request canceled. It does not undo commits that were already pushed. If a push completed before cancellation, revert or correct it through your normal Git process.

Troubleshooting

The merge status and system logs identify whether failure occurred during repository access, resolution, validation, commit, or push.

Symptom	Resolution
Pull-request URL is rejected	Confirm it is a supported GitHub or Azure DevOps pull-request URL and the workspace credentials can read it.
An active merge already exists	Finish or cancel the existing merge for the same ticket or source branch before retrying.
Fetch or clone fails	Verify repository URL, DNS/TLS reachability, credentials, and read access from the session host. Check system logs for the Git exit code and error.
Catch-up merge fails	Check system logs to distinguish a fetch failure, conflict-inspection failure, or non-conflict merge failure before retrying. Confirmed conflicts reopen review.
Push is denied	Grant the credential push access or update branch-protection rules; prefer pushing to the pull-request source branch when direct target updates are prohibited.
AI assistance fails or times out	Continue with Skip AI and resolve manually, or correct model connectivity and retry with a new merge request.
A file changed after review began	Cancel and restart so the baseline and branch tips are current.
Server stopped during a merge	After restart, inspect the request status and logs. Stale temporary workspaces are cleaned automatically; start a new merge if the request failed.

Never paste repository credentials into conflict content or messages. Rotate the credential if a secret is exposed in a branch, log, or generated resolution.