Multiple developers review pull request

[Florian Peschka]

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?

[G__Sylvie_Davies__bit-booster_com_ · Accepted solution]

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: https://answers.atlassian.com/questions/16877304

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

[Florian Peschka]

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

[Felix]

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,

Felix

[Florian Peschka]

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.