Multiple developers review pull request

Our workflow currently dictates that every pull request needs at least one reviwer. So far, so normal. But now we have the situation where two developers are working on the same feature. (We do not use the Branching Model provided by Bitbucket).

I say that both should work in the same feature/xyz branch, because that will nicely "package" the feature into a single branch.

The problem is that when creating a pull request, the creator cannot be a reviewer. But in this case, he should be, because the pull request also contains commits of other people, that he needs to review himself.

How could we handle this better?

2 answers

1 accepted


I recommend voting for BSERV-4462 - Allow Pull Request Owner to approve his own Pull Request and leaving a comment on it, since your usecase makes a lot of sense and isn't mentioned there.

Meanwhile, take a look at the answers and comments on the related Atlassian Answers question:

The workaround based on that answer is to get a 3rd person to create the PR.

(Side note to Bitbucket Server development team:  I believe Bitbucket Cloud does let PR creators approve their own PR's!)


p.s.   I invite people to try out my add-on:  Bit-Booster for Bitbucket Server


I think that's what we will do for now - just have the project/release manager create the PR. Still I added my comment to the Issue you linked, although it's already marked as closed...

1 vote

On the Bitbucket team we tend to do things in a similar way, however we don't ever review our own pull requests. 

Here's what we do: 

  1. Create feature/xyz branch from master (our stable branch)
  2. Create branches from feature/xyz for each individual subtask
  3. Create a pull request to feature/xyz and have 2 people that did not write the code review it
  4. When the feature is "ready" (or we feel the changes can go to master), create a pull request from feature/xyz to master. All the code on the feature-branch will have been reviewed already, but we usually do another "holistic" review of the changes.

With this model, if there's 2 developers and one "informed reviewer" working on a feature, we can make sure that there's always at least 2 approvals on a pull request, and no developer needs to approve their own changes. It also ensures the feature only goes to master when it's ready, and master remains stable. Because everything is still in the feature/xyz branch, everything is "packaged" nicely in a merge commit, so should we need to revert the change for any reason, we can.

I hope that helps,


Yeah that's how I imagine would be the "correct" way to do it. But to me it just seems clumsy to create branches just because the system doesn't allow the PR creator to be a reviewer. So it's a workaround for a problem that is purposefully imposed upon you by the system instead of (how it should be) the system helping you facilitate your own workflow that works best for your team.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 06, 2018 in Bitbucket

Upgrade Best Practices

Hello! My name is Mark Askew and I am a Premier Support Engineer for products Bitbucket Server/Data Center, Fisheye & Crucible. Today, I want to bring the discussion that Jennifer, Matt, and ...

1,952 views 7 10
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