How can I solve a conflict in a pull request?

Suppose I have two branches, master and release/2.0, and I want to merge the release branch into master.

I do a pull request to merge release/2.0 to master, but, after the pull request has been done, I discover that there is a conflict (for example, application's version within the main POM).

How can I solve the conflict? Is the previous one (direct pull request in BitBucket) the right approach, or I have to perform the merge in my local environment and then make the pull request? In this case, which are the steps to perform?

Thanks in advance.

5 answers

1 accepted

Accepted Answer
10 votes

You have two options to resolve the conflict:

1) Resolve them without a pull request.

To do this, you would checkout the master branch, and then pull in the release branch. This is effectively the solution that Bitbucket Server give you when you ask for more information on how to solve the conflict.

$ git checkout master
$ git pull origin release/2

<resolve merge conflicts and commit>
$ git push

2) Resolve them with a pull request

To do this, you would create a branch off the tip of master, pull in the release branch and create a pull request from that branch to master. This is the best option if you don't have permission to push directly to master.

$ git checkout master
$ git checkout -b resolve-conflicts-branch
$ git pull origin release/2

<resolve merge conflicts and commit>
$ git push -u origin resolve-conflicts-branch
<create pull request>


Note: Once you have resolve the conflicts through either of these methods, your old pull request from release/2 to master will be closed automatically since there will no longer be any diff.

The second solution is fine for me.

1) Works for me, before i push i had to commit

perform the merge in reverse locally, merging master into release/2

git checkout release/2
git merge master

then manually resolve any conflicts, commit and push

git commit
git push

Your pull request should automatically update itself to the new commit and there are no longer any conflicts (because you just resolved them all)


You could also use a rebase instead of a merge.  This gives a cleaner look to your history, at the cost of a little bit of historical accuracy.  Many people think that's a good deal.

git checkout release/2
git rebase master
&lt;resolve conflicts manually&gt;
git push

As before, your Pull Request should now be mergeable




Hi @Tim Crall,

I need to merge the release branch into master; does your solution do the opposite?

It does the opposite locally as a means of resolving the conflicts between them.  It then uses the Pull Request to do the actual merge in the correct direction.

When you push onto release/2 you are have effectively merged master into release/2. This is not what you want to do if you would like your release branch to not contain all the commits that exist on master.

True.  I was kind of assuming you'd be deleting the release branch after merging it into master.  

In GitFlow branching strategy, a release branch should usually be deleted (or at least abandoned) after the release was finalized, which is when you would merge it back into master.


We've developed a plugin, Power Editor for Bitbucket, that allows you to resolve conflicts on a pull request in the UI. You won't need to go through any of the git commands anymore smile (even though we highly recommend you learn them, they can be quite useful). You can check out out here.

It also supports:

  • Adding, renaming and deleting files
  • Editor extensions like preview, view diff and tab and space controls.
  • Editing functionality in pull requests to quickly fix typos in files.
  • Full support for hooks.

I resolve locally, w/ a non-fast forward merge from the target branch into the source branch.  A word about non-fast forward merges, they create an easily rescinded commit should you require a rollback.

1. Checkout to master, get latest, checkout to your release/2.0 and non-fast forward merge master in to it:

git checkout master && git pull && git checkout release/2.0 && git merge --no-ff master

2. Your output will indicate which files are conflicting.  Iron out those conflicts.

3. Commit the conflict resolution, push your release branch back up for a clean pull request.

git commit -am "resolve merge conflict" && git push


@Casey Wise, maybe I'm misunderstanding your comment but it seems to me that this will result in all the changes from master being on the release branch.

If you then want to make a bugfix to that release branch, you may not get what you expect because it will contain all the changes from master too - which may be API breaking, contain extra features etc and is against the rules of SemVer.

@Kristy Hughes If there's broken or unnecessary code on master you don't want cleanly merging w/ your release/feature/hotfix, someone owes the office donuts and/or bagels!

git blame


Its not that there is broken code on master, but that the release branches should be strictly behind master. Master will contain the newest features, which you might not want merged into old release branches for the sake of compatibility.

0 votes
M S I'm New Here Sep 30, 2018

Why is there no online web GUI app that makes the merging easier?

I don't want to deal with command line when needing to resolving conflicts. GitHub already has an online tool that does that.

There is a feature request for this you can vote on and watch:

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Aug 21, 2018 in Bitbucket

Branch Management with Bitbucket

As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual wo...

2,341 views 9 12
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you