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