It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How can I solve a conflict in a pull request?

Omar Crea Jun 10, 2016

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.

8 answers

1 accepted

22 votes
Answer accepted
Kristy Hughes Atlassian Team Jun 10, 2016 • edited Aug 28, 2018

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.

Omar Crea Jun 13, 2016

The second solution is fine for me.

Like York Yang likes this
Stefan Wendelmann Aug 28, 2018

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

Carol Skelly I'm New Here Feb 11, 2019

But solution 1 pushes back to master and closes the pull request which we don't want if the PR is still pending review/approval, correct?

Like Ron Hiepel likes this
Kristy Hughes Atlassian Team Feb 11, 2019

Correct, however the pull request that has been automatically opened doesn't have any reviewers by default. So it's totally up to your team how you would like to handle them. If you want the merge conflict resolution to be reviewed, then you should go with option 2 where you open a new pull request on a branch with a different name (but the same head commit). Once that pull request has been reviewed and merged, the initial pull request will be automatically closed so you don't have to worry about it.

If your team doesn't feel like it is necessary to have reviewers on all pull requests, or doesn't feel like it is necessary to review merge conflict resolution changes, then they can just go for option 1, which is a little bit less convoluted.

Like Mario Heleno likes this
Mario Heleno Apr 26, 2019

Hi @Kristy Hughes is it possible to add in answers the process for Mercurial repos?

I'm know it not widely used as git but it is what we have here.

Kristy Hughes Atlassian Team Apr 28, 2019

Hi Mario,

This question is specifically about the automerge feature of Bitbucket Server. Bitbucket Server does not support Mercurial, which is why the answer is git-specific.

If you have a question about merge conflicts in Mercurial, I suggest that you create a new post for it and tag it as "Bitbucket" (not "Bitbucket Server") so that you are able to give all the details of your question.




Like Mario Heleno likes this
Mario Heleno Apr 29, 2019

Ok. Thanks

Muhammad Tahir May 13, 2019

Steps DONE

git pull

git checkout <feature_branch>

git pull origin <destination_branch>
git add <filename>
git commit -m'commit message'

When I tried to run ->

git push origin <feature_branch>

I got the following error 

error: src refspec <BRANCH-NAME> does not match any.


error: failed to push some refs to 'PRIVATE_URL'

Can someone tell me reason ?

6 votes
Tim Crall Jun 10, 2016

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




Omar Crea Jun 10, 2016

Hi @Tim Crall,

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

Tim Crall Jun 10, 2016

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.

Kristy Hughes Atlassian Team Jun 10, 2016

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.

Tim Crall Jun 13, 2016

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.


Barrie Pfeifer Dec 10, 2018

Digging up old threads....  Is there a way to config Bitbucket to only merge if the source branch is already up to date with the destination?

Kristy Hughes Atlassian Team Dec 10, 2018

@Barrie Pfeifer, yes there is.

You can configure the merge strategies to only allow fast-forwards.

However, depending on your configuration this might make it difficult to make sure your branch is always ahead of the destination and also give enough time for a green build (because rebasing will change the commit hashes, and hence the builds). Of course if you don't have frequent changes to the destination branch and your pull request builds are fast then it will probably be ok.

Depending on your use case, you may also be interested in the Auto-unapprove plugin that will reset the reviewers' approvals when there are meaningful changes on the destination branch. If this is coupled with a merge check that ensures that the reviewers have approved then it can also block the merge.

Hope this helps,


Ron Hiepel Mar 07, 2019 • edited

Instead of doing

git merge master

you might want to consider fetching the remote branch first or simply do

git merge origin/master

Your PR will be updated accordingly (commit and push) and all merge conflicts should be resolved.

2 votes
M S 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.

Kristy Hughes Atlassian Team Oct 01, 2018

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

0 votes
Mohammed Davoodi Feb 16, 2017

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.
0 votes
Casey Wise Sep 13, 2018 • edited

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


Kristy Hughes Atlassian Team Sep 13, 2018

@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.

Casey Wise Sep 14, 2018 • edited

@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


Kristy Hughes Atlassian Team Sep 16, 2018

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.

Like Eliezer Ramos likes this
Casey Wise Sep 17, 2018


0 votes
wahid algerien Nov 05, 2018 • edited Nov 06, 2018

When you push onto discharge/2 you are have successfully combined ace into discharge/2. This isn't what you need to do on the off chance that you might want your discharge branch to not contain all the submits that exist on aceClean Master Facebook Lite Mathway

0 votes
David Latty Feb 06, 2019

The problem is if any of the merged code is postponed or abandoned (e.g. to requirement needs) your master ends up with code - and this is bad as that code may likely be issued. It may also not have been the last commit. What happens then?

0 votes
Kidane Yosief I'm New Here Friday

you would need to resolve the conflict in your branch first.


git checkout yourBranch

git merge origin/master

resolve your conflict

git add . && git commit -m "conflict resolve" && git push

This way your pull request will look fine. 

it can be reviewed and merged perfectly ... 

Kristy Hughes Atlassian Team Friday

This would usually work for most branches, however the example that has been posted is for a release branch merging into master. Most of the time, there would be branch permissions set up to stop you from pushing directly to release branches so this approach may not work in those cases where you do not have permission to push to the branch.

Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Published in Bitbucket Pipelines

Building a Bitbucket Pipe as a casual coder :  #!/bin/bash source "$(dirname "$0")/" enable_debug extra_args="" if [[ "${DEBUG}" == "true" ]]; then extra_args="--verbose" fi # mandatory variables R...

3,030 views 1 20
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you