## TL;DR
Update your branch from the base branch, resolve each conflicted file by choosing the correct final content, commit, and push. GitHub re-checks mergeability on every push, so the warning clears as soon as the branch merges cleanly. Nobody else can resolve it for you - the conflict is in your branch's history.

## The error
```text
"this branch has conflicts that must be resolved" how to fix
```

## Steps to fix
1. Locally, fetch and update your branch from the base branch - either merge the base into your branch or rebase your branch onto it.
   - Expected: git lists the conflicted files and stops.
2. Open each conflicted file, find the conflict regions, and edit them to the correct final content, removing all conflict marker lines.
   - Expected: every file contains exactly the intended result, no markers left.
3. Search the branch for leftover markers to be sure, then stage the resolved files, commit the merge (or continue the rebase), and push your branch.
   - Expected: the push succeeds and the PR timeline shows the update.
4. Reload the PR.
   - Expected: the conflict warning is gone and the merge button is back.

## Use this when
- The PR merge box shows "this branch has conflicts that must be resolved".
- The base branch moved forward after you branched.
- You have push access to the PR branch.

## Not for this skill when
- The blocker is a failing check or missing review rather than conflicts.
- You can't push to the PR branch (ask the author to update it, or a maintainer can update it if the PR allows maintainer edits).
- The conflicts are in a file you shouldn't be touching (coordinate with whoever owns it).

## Variant phrasings
- this branch has conflicts that must be resolved
- PR merge conflicts how to resolve github
- branch conflicts must be resolved before merging
- fix merge conflicts pull request

## Why it happens
Someone else changed the same lines on the base branch after you branched. Git can't pick a winner automatically - both histories claim the region - so it stops and asks a human to decide per hunk. The PR is otherwise fine; only the overlapping regions need decisions.

## Edge cases
- Binary files can't be merged by hand: pick one side's version and move on.
- Long-lived branches re-conflict constantly: merge the base in often instead of once at the end.
- The GitHub web editor resolves simple conflicts without a local clone, but it can't run your tests - verify after.
- Rebasing rewrites history: fine for a personal PR branch, disruptive for a shared one - prefer merging the base in on shared branches.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pSEcIdKev9nOqdQMrgA8Mw