allow for pull requests to require approval (BB-6920)

Issue #5652 resolved
Devon IT
created an issue

We would like to modify our workflow to require that a pull request requires as least two approvals from the team in order to merge into our master tree. Is this is already possible with bitbucket?

Obviously we can simply tell our project leads not to accept a pull request until two approvals show up, but we try to maintain a team-based mentality where no single member has totalitarian control. Having said that, it is sometimes difficult to ensure that every single change that makes it in has indeed been reviewed by multiple parties.

Official response

Comments (100)

  1. Devon IT reporter

    I am often confused by Atlassian's offerings.. We have been moved from FeCru to Bitbucket, yet it seems that Stash provides the same features as Bitbucket plus some fine grained control?

    Why was this not discussed in the migration documentation? Furthermore, why are there two products that provide git support from Atlassian instead of having, for example, an "enterprise" package for bitbucket? We'd probably pay for it.

    Also, is Stash a hosted solution?

    Finally, I'm a bit put off as a paying customer that the answer to this is simply "we're not going to do that." We're developers, can we help? Is there a way for me to get the community to upvote this feature to impress upon you that it may be worth the development time? In fact, because you already have the ability to approve a pull request, it occurs to me that something like this might not be such a technical hurdle. If not here, where does one go to pursue a feature like this?

  2. Wyatt Anderson

    Wow, I didn't even know Stash existed. We were also migrated to Bitbucket from OnDemand SVN and would probably have gladly switched to Stash if it was available as a hosted solution.

    I'll echo the desire for an "enterprise" package for BitBucket.

  3. Doron Gill

    Echoing everything said here. Having this feature would be great. The move to Stash does not help as its not available as part of the onDemand suite. Atlassian should get its act together as far as treating its customers better

  4. Pawan Agarawal

    Our team could really, really use this feature, as well. With a growing team and lots of people trying to merge code, it would be very nice to be capable of putting some restraints on when people can merge to minimize the risk of breaking master.

  5. Richard Simpson

    Agreeing with previous comments. If I have to spin up Stash on local infrastructure just to use this feature, I'd much rather use GitHub Enterprise then dealing with that hassle. I imagine a lot of smaller business feel exactly the same way.

  6. Zachary Davis

    This isn't currently planned. However, we have an upcoming project that this may be a part of. I'll know more once planning for that project gets under way.

    If not sooner, I'll be back in a month to provide another update.

  7. Jason Gerard

    With 110 votes, this really should have higher priority. The plugin for Stash which required x number of approvals before merge was the only way I was able to even get git passed my security and compliance auditor at my last organization. Features like this will do nothing but increase your enterprise adoption.

  8. Scott Wang

    all stash or (bitbucket server) functionality should be added to Bitbucket, two code bases shouldn't be an excuses. Both are paid solutions, the only difference to me is one hosted by Atlasssian and one hosted by your own, but the functionality of each shall be the same.

  9. Nenad Miksa

    +1 We also need that feature.

    Btw, isn't BitBucket cloud run by the same software as BitBucket Server/Stash? So why is this feature disabled in BitBucket Cloud?

  10. ped zed

    We're working on this! I don't have a firm delivery date, but it's in progress. I'll post a status update in May.

    At last! I was looking and waiting so long for this feature.

  11. Joshua Fox

    This would be very useful. The SAAS Bitbucket is what we need, not the hosted version, but we would like to have the ability to require two approvers, and to define the lists of people authorized for the first and second step of approval.

  12. Benjamin Echols staff

    We're still working on this. We're planning to support both repo and branch level controls, so you can apply some settings to a whole repo but really lock down the most critical branches. Progress has been good, but as you all know, the devil's in the details.

    More to come in June!

  13. Sean Timm

    @benechols - I'd love to see the PR author's self-approval optionally required as a condition for merge, though. We've been in situations where someone submits a pull request for review but doesn't intend for it to be merged quite yet and is just looking for early feedback.

  14. Sergey Pauk

    Hope that this feature also includes a "Requires all tasks to be resolved" option (it's available in BitBucket server)? Or is there another ticket for this?

  15. Benjamin Echols staff

    Unfortunately we've hit a snag, and this feature will be delayed. I'm truly sorry for the delay - we're making an effort to communicate better, and I recognize this is frustrating.

    I'll post updates here when we have more to share.

  16. André Mazoni Wanderley

    Hey, guys. I made an extension some time ago that does just that. It's not perfect (anyone can re-enable the button lol) but it's something (btw, sorry for not having this functionality in the screenshots. I'll work on that later). I'm open to suggestions.

    The repo is here, in case you wanna contribute:

  17. Benjamin Joldersma

    I'm surprised this isn't in. What's the status? We used this when we had stash previously. Also, what's the deal with being able to approve own PRs? That seems a bit odd. @benechols ?

  18. Andrew Boyd

    We need this feature so badly, currently we use an admin account to merge pull requests to make sure everyone has approved without a sneaky merge going on, it consumes way too much time, not to mention the build server then builds it twice because it's been merged by 2 users. @benechols, can you give us a rough estimate as to how much longer?

    Also, are there any plans to introduce the "Requires a minimum of x successful builds" feature?

  19. Anonymous

    Navigate to "/admin/branch-permissions" within your repository, there's a new "Merge via pull request" option for branch permissions. I just set branch to master, don't give anyone access to write & set my developers group to Merge via pull request

  20. OscarG

    @ICTteam_ec I think that has been there for a long time, we already use it, but the requirement that we are after is a bit different:

    "We would like to modify our workflow to require that a pull request requires as least two approvals from the team in order to merge into our master tree. Is this is already possible with bitbucket?"

  21. Anonymous

    yeah, sorry about that. I'm fairly certain the Merge via pull request feature wasn't there which is what I was excited about, but surely number of approvals and successful build isn't far behind :)

  22. Lakshminarayanan Krishnan

    @OscarG - how do you reply to a comment? I am unable to do so - basically I too wanted to tell ICT-Team the same thing you said - this is such a basic feature that worked so well for CI/CD builds in gerrit. Heck, BB even has this feature in Stash - why aren't they offering it here. Same is the sad story for another BB issue - 7667

  23. OscarG

    @Lakshminarayanan Krishnan replying seems to be another missing feature of this forum, I just make a comment like you did. I think we can just look for alternatives to BB, this issue was created 4 years ago! and the last update from Attlassian 3 months ago is that it is delayed :( ... very dissapointing. What other options are you all considering, We are thinking AWS Codecommit + Gitlab.

  24. Lakshminarayanan Krishnan

    @OscarG - We're only partially into our migration from Perforce to Bitbucket, so if I suggest a shift to another hosted-solution, my CEO might possibly murder me :D .. We also picked up BB because it was like just a dollar extra per user over our existing JIRA license. Do AWS Codecommit & Gitlab offer same / similar solutions as BB? I'm sorry I haven't really checked other options thinking that selecting BB would be a good decision. I mean, it still is - BB doesn't charge based on number of repositories you host (unlike Github). Just that they are pretty slow to implement important features.

  25. OscarG

    AWS Code commit is also $1pm after the first 5 users ( but it is only the repo and does not have the UI, that's why GITLab, which has a free community edition ( additionally, there is no repository size restriction in AWS. We already host many of our services in AWS that's why AWS is an option. Also Gitlab supports this feature already (

  26. Mehmet Catalbas


    Why did you try to support it per branch level to begin with? It doesn't even have to be that granular for starters...

    So many kittens have died and people started to kick babies in the last 4 years because of this missing feature.

    Guys, OK, I know you've worked on this but did you really break this into smaller chunks and estimated them? Maybe I'm wrong, but to me, doing this on the repository level is a single developer's %20 time, so working on it on a Friday, testing & improving it on Monday and it could have been released to masses by Tuesday... Simple, require N many approvals before any pull request can be merged setting on the repository admin for a starting point. That's all. After all, you have all the information, there needs to be greyed out Merge button on the frontend side when there's not enough number of approvals set per repo and a validation on the backend side.

    This is not a snarky comment whatsoever, I'm very happy to have been using your service for many many years now. But this should've been released long time ago with primitive features. After all, we've been advocating for being Agile for this particular reason, particularly to avoid long running frustration and customer dissatisfaction.

    Two cents.

  27. James Grodskiy

    Hey everyone, for us today we noticed a new section in branch permissions when creating a rule for a specific branch, called merge checks. There was a note it requires a premium cloud account. So not free? Looks just like the merge checks for the bitbucket server.

  28. Philip O'Gorman

    @bechols We have 18 users, we pay $25/month ($300/year). Our cost will go to $90/month for this feature ($1080/year)!? That's a a pretty dramatic cost increase for a straight forward feature. Whats the justification for the large price increase? What other features can premium users expect? Can this feature be limited to only the reviewers in the team?

  29. Benjamin Echols staff

    We believe Premium is competitively priced for the features, performance, and uptime we offer. The Bitbucket Premium plan is for professional software teams who need better control and accountability over their workflow, so we will continue to add more administrative, security and auditing features.

  30. Philip O'Gorman

    @bechols in our case none of our code base is supported by Pipelines and we don't need GFS. If you plan to add more features in the future, that's fine, charge for them when you have them, or at least give us a roadmap. This has a feeling of "bait and switch". The simplicity and cost or your previous plans was what attracted us here in the first place. This will most likely make us move to the server solution - maybe that's the intention?

  31. Derek Dalessandro

    there is nothing in the premium documentation about performance and uptime for this new service level. as far as I can see, we'll get billed +$3/user/month to use one feature (to require pull requests). that is not worth it. the other functionalities touted in the premium feature set are not applicable to me. Perhaps there are others that will be interesting if there is a roadmap available.

  32. Jelmer Verkleij

    This is a pretty steep price increase for what should be regarded as core functionality. Like others I have absolutely no need for GFS or Pipelines, and even if I would be using that this price increase more than doubles the amount of money that goes to Bitbucket. That is rather disproportionate.

    With the extremely slow uptake on this issue (and several others), the lack of communication about it and the general service level from customer support I don't feel like paying you anything more than we do already, let alone this much - especially if you're justifying this price increase with a lot of future feature implementations. Nothing about the way you handled this case suggests these features will be around before the next decade, so excuse me if I don't feel like paying you hundreds of dollars for several years awaiting those features which probably aren't even necessary for us.

    I would also like to point out that this puts into perspective the fact you disabled comments on the blog recently, just before posting the announcement of this price hike on that same blog. Were you afraid for some negative comments and backlash? Because if you were, that was justified and pre-emptively silencing public feedback channels does not feel like you're very intent on handling any of it.

  33. Adam Knights

    I agree, gitlab's enterprise offering is $3.25 per user per month and has way more features than your current premium offering. I'll be recommending we move there.

  34. Joshua Fox

    +1 on the price. The multiple-approvers feature is important, but so are a lot of others, and this step up in functionality is not worth a much-increased price. (If I understand correctly, the price is times-5)

  35. Lakshminarayanan Krishnan

    Similar to what @Philip O'Gorman said, we have 75 users and are on the 100USD per month plan (1200USD per year), and for just having the need for the only one useful feature that you have implemented - merge checks - our cost is going to jump to 75*5 = 375 USD per month (4500 USD per year) - EXTREMELY steep increase for a very basic feature that should have been implemented a long long time back. Pipelines - you do not even support the platforms we have, and GFS is something we have no need for.

    This is as bad a money-making strategy as in-app-purchases for "free" games.

    The more we think about this, the more we are thinking moving to Gitlab is a better option now. This bait-and-switch tactic was something we had hoped Atlassian wouldn't stoop down to, but now you have practically fooled us by becoming "just another company".

  36. Nenad Miksa

    Here is one premium feature I would like to have (I think it would be worth to pay $5/user/month for it): I want to be able to like someone else's commit. And for each like, a little heart should be displayed next to commit.

  37. Log in to comment