By out of date, we mean a pull request that is based on an earlier version of the target branch. The problems with this are:

  • there may be conflicts, in which case it would not be mergeable

  • when the merge happens, the result is unknown - the merge result has not been built on either the topic or target branch

This will inevitably happen as changes are pushed or merged on to the target branch (for instance master). But there is no reason why the pull request can’t be created from the tip of master…​ this will give reviewers the best chance of being able to merge without conflicts, and a green build from the topic branch will mean you will get a green build after merging (as the inputs are the same).

We are trying to avoid this situation:

If a pull request is created from topic now, the merge result is unknown, and it may be conflicted. If this listener is applied, you will see the message:

There is no need to lose any additional information that has been added in the description. In a command prompt window, rebase or merge your topic branch:


git checkout topic
git rebase master
git push -f

Alternatively to merge rather than rebase:


git checkout topic
git merge master
git push

Once done, press the Create button again.

It’s possible that the developer will need to resolve conflicts when rebasing or merging the branch, however they were going to have to be resolved sooner or later, so better to do it sooner whilst it’s fresh in their mind.

Another way of ensuring that the merge will produce a green build, is to build from the automatic merge that Bitbucket will do when a pull request is rescoped (i.e. when either branch gets new commits):


git fetch origin  +refs/pull-requests/{id}/*:refs/remotes/origin/pull-requests/{id}/*

where {id} is the ID of the pull request in question. If there is no ref pull-requests/{id}/merge it means there were conflicts. There is interesting further reading here.