Multiple developers review pull request

Florian Peschka February 15, 2017

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

2 votes
Answer accepted
G__Sylvie_Davies__bit-booster_com_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 16, 2017

 

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 February 16, 2017

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
Atlassian Team members are employees working across the company in a wide variety of roles.
February 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,

Felix

Florian Peschka February 16, 2017

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
TAGS
AUG Leaders

Atlassian Community Events