## TL;DR

The target branch moved and your MR no longer merges cleanly. Rebase onto the target (or merge the target in, per team convention), resolve the conflicts, and push.

## Error

```text
This merge request has conflicts that must be resolved before merging.
```

## Steps

1. Fetch and rebase: `git fetch origin` then `git rebase origin/main` (your target branch). Expected: git stops at conflicts.
2. Resolve each conflicted file, `git add`, `git rebase --continue`. Expected: the rebase finishes.
3. Force-push with lease: `git push --force-with-lease`. Expected: the MR updates and the conflict warning clears.
4. Confirm the pipeline re-runs on the new head. Expected: the MR is mergeable once green.

## When to use

- The GitLab MR widget reports conflicts that must be resolved.
- The target branch advanced under your MR.

## When not to use

- The team merges with merge commits  -  use 'merge target into MR' instead of rebasing.
- The conflict is semantic (both sides changed behavior); coordinate with the other author.

## Tool compatibility

- GitLab merge requests.
- Git 2.x.

## Variant phrasings

### Conflicts in generated files

Regenerate on top of the new target instead of hand-editing.

### MR shows conflicts immediately after creation

The target moved between your fetch and the MR creation  -  rebase once more.

## Why it happens

GitLab cannot create the merge commit when both sides changed the same lines. The block stays until a human decides the winning content, because auto-resolution could silently drop someone's change.

## Edge cases

- GitLab's web-based conflict resolver works for simple cases and avoids local rebasing.
- Rebasing rewrites SHAs  -  tell collaborators on a shared MR branch first.

## Provenance

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