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

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
Felix Atlassian Team Feb 16, 2017

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
Posted in Bitbucket

Contest: Share your custom Bitbucket Pipe and win

Announced in this blog, this holiday season we’re celebrating all things CI/CD and between now and the end of 2019 we’ll be showcasing content, use cases, feature announcements and more. One featur...

592 views 2 4
Join discussion

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