> ## Documentation Index
> Fetch the complete documentation index at: https://docs.assert.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Merge Candidates

> Keeping a pull request current with its base branch without rebasing locally

Your pull request was opened against `main` at some commit, and `main` has moved
since. The reviewer is reading code that will not be what ships, and the author has
to stop, rebase, resolve conflicts, and force-push, which throws out everyone's
in-progress review. On a busy repository this happens constantly.

## What Assert does

When the base branch moves ahead, Assert builds a **merge candidate**: the pull
request already merged with the current tip of its base branch. If that merge
conflicts, an agent resolves the conflicts in an isolated sandbox.

The candidate's state shows in the review header.

<img src="https://mintcdn.com/assertlabs/FvVy5ZggEJSKHhfc/images/merge-candidates/candidate-ready.png?fit=max&auto=format&n=FvVy5ZggEJSKHhfc&q=85&s=7cfa2159251064bc9044e850988a697e" alt="The Clean candidate ready pill in the review header" className="rounded-lg" width="636" height="74" data-path="images/merge-candidates/candidate-ready.png" />

| State                 | Meaning                                                                                  |
| :-------------------- | :--------------------------------------------------------------------------------------- |
| Up to date            | The base branch has not moved.                                                           |
| Preparing merge…      | Assert is building the candidate.                                                        |
| Loading diff…         | The candidate exists and its diff is loading.                                            |
| Clean candidate ready | Built and reviewable.                                                                    |
| Merge unavailable     | No candidate is available for this pull request. Get in touch if you were expecting one. |

<Note>
  The **Merge commit** dropdown beside the pill sets how the pull request itself lands
  on the base branch once it is approved — merge, squash, or rebase.
</Note>

## Reviewing the candidate

Opening the candidate gives you a file tree and diff for the merged result.

<img src="https://mintcdn.com/assertlabs/FvVy5ZggEJSKHhfc/images/merge-candidates/diff-of-diffs-view.png?fit=max&auto=format&n=FvVy5ZggEJSKHhfc&q=85&s=2241e1391370d553dcb232a483e1c9ed" alt="The merge candidate dialog showing the merged result as a diff" className="rounded-lg" width="2316" height="1856" data-path="images/merge-candidates/diff-of-diffs-view.png" />

The author's own work stays distinct from the code the merge brought in, so you can
read the resolution before accepting it.

## Promoting

**Update branch with merge commit** adds a merge commit to the pull request's
branch, bringing in the latest base branch. The branch you reviewed becomes the
branch that merges, and nobody rebases locally.

This is a merge commit, so history is never rewritten and nothing is force-pushed —
if you have the branch checked out, `git pull` is enough.

Once promoted, [Re-review](/reviewing/re-review) separates the author's new work
from the code the merge brought in.