GitHub · Pull requests · Git · Checked October 27, 2026

GitHub: a pull request has merge conflicts

Merge conflicts happen when people make different changes to the same line of the same file, or when one person edits a file and another deletes it. Git cannot safely choose which version to keep, so all conflicts must be resolved before a pull request can be merged on GitHub: while it has a conflict between the compare branch and the base branch, Merge pull request is deactivated (GitHub's merge conflicts, checked October 27, 2026).

$ git merge BRANCH-NAME
> CONFLICT (content): Merge conflict in styleguide.md
> Automatic merge failed; fix conflicts and then commit the result

Two kinds of conflicts

Competing line changes: both branches changed the same lines. In the file, the changes from HEAD or the base branch come after <<<<<<< HEAD, then =======, then the changes from the other branch and >>>>>>> BRANCH-NAME.
A removed file: one branch deletes a file that the other branch edits. git status lists it under the unmerged paths, for example as deleted by us.

Resolving on GitHub

The conflict editor: simple competing line change conflicts can be resolved on GitHub. Near the bottom of the pull request, click Resolve conflicts, keep one side, the other, or a new change, delete the conflict markers, click Mark as resolved for each file, then Commit merge (GitHub's resolving a merge conflict on GitHub).
Resolve conflicts deactivated: other conflicts, such as a removed file, are resolved with another Git client or on the command line.
The whole base branch: resolving conflicts on GitHub merges the entire base branch into the head branch. If the head branch is the default branch or a protected branch, you may be asked to create a new head branch, and for a protected head branch you must: Create branch and update my pull request.

Resolving on the command line

Competing lines: git status lists the files as both modified. Edit each file, delete the conflict markers, then git add . and git commit.
A removed file: git add FILE keeps it and git rm FILE removes it; then commit.
Back to the pull request: push the resolution to the pull request branch, then merge the pull request (GitHub's resolving a merge conflict using the command line).

What to do

Simple line conflicts: Resolve conflicts on the pull request page, then Merge pull request.
Anything else: in a local clone, merge the base branch into the pull request branch, resolve the conflicts, commit and push back to the pull request branch.
Not Update branch: GitHub updates a branch only when there are no merge conflicts, and refuses with merge conflict between base and head otherwise (see why updating the branch was refused).
The same conflicts after a squash merge: if you keep working on a branch that was squash merged, later pull requests can include the squashed commits again, which makes conflicts more likely and can mean resolving the same conflicts more than once (see commits already squash merged in the next pull request).

In IntelliJ IDEA: "Branch has conflicts that must be resolved"

The GitHub pull requests built into IntelliJ IDEA show "Branch has conflicts that must be resolved" in a pull request's status, with a Resolve link. In the source (checked October 30, 2026), the line shows when GraphQL gives the pull request's mergeable as CONFLICTING ("The pull request cannot be merged due to merge conflicts"). While it is UNKNOWN ("The mergeability of the pull request is still being calculated"), or before the answer has come, the line reads "Checking branch for conflicts" instead (GitHub: MergeableState; IntelliJ IDEA: GHPRMergeabilityStateBuilder.kt, GHPRResolveConflictsLocallyViewModelImpl.kt, CodeReviewDetailsStatusComponentFactory.kt). Resolve asks whether to rebase or merge, fetches the base branch, checks out the pull request branch, and then rebases it onto the base branch or merges the base branch into it. Any conflicts are then resolved in the IDE, and the pull request changes only when you push; after a rebase, that push has to be a force push (ResolveConflictsLocallyViewModel.kt). Resolve is greyed out, with the reason on it, for example while the repository is in the middle of a merge or a rebase ("Merge is already in progress"), and when the current branch already tracks the pull request branch and has the latest commit of the base branch in its history ("Already resolved locally, push your changes to resolve") (CollaborationToolsBundle.properties). There is an open report that "Checking branch for conflicts" stays on a pull request after it is merged (IJPL-162938, open on October 30, 2026).

GitHub pull requests in IntelliJ IDEA

Pull Request Inbox for GitHub, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, shows a pull request's reviews, checks and conversations next to the diff, and merges it with the methods the target branch allows. Its merge checks say when a pull request has conflicts with the target branch, among the ones that block the merge, which come first, and say to resolve them with Resolve conflicts on GitHub or to merge the target branch into the branch locally and push; it does not offer Update the branch while the pull request conflicts, as GitHub refuses it. The review inbox, diffs and conversations are free; approving, commenting, resolving and merging are Pro (US$1.50 a month, with a 30-day trial).

GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitHub, Inc. or JetBrains.