Approval to merge, failure of understanding.

[Lee Noble]

Summary: I'm attempting to use branch permissions to enforce some code review among developers but I don't want the repo admin to have to perform the merge operation, and also not within BitBucket. I keep seeing the phrase "merge via pull request" but no description of what that is or how to accomplish it.

Long version: I (repo administrator) have a repo with a master branch. I've set branch permissions Write access: none, Merge via pull request: Developer Bob, Check for at least 1 approval.

Now, Developer Bob makes a new branch and commits to it. Then submits a pull request to master. I log in and approve the pull request but then BitBucket invites me to perform the merge. I do not want to perform the merge and I particularly don't want to perform the merge within the BitBucket web interface. I want Bob to merge his branch and push to master. Bob is using SourceTree locally but whenever he attempts to push he gets a permission denied on branch master error. So what's a "merge via pull request"? How does Bob merge via pull request.

Background: The team's usual workflow was unrestricted. All devs merge and push to master within SourceTree or on the CLI and then deploy to staging and/or live. All I'm trying to introduce is a layer of code review and sharing of project knowledge. Giving ownership of a project to one or other developer to review all commits intended for master will provide a minimal level of this but this will be a vast improvement. If I can avoid devs merging straight to master without approval then that would be great. I don't really want to perform merge operations in the BB web interface as this is a bigger departure from established practice. I've read several threads on this site and most just point to the documentation for branch permissions, but it's not doing what I expect based on what I've read there. I thought perhaps devs would have to "fork" the main repo within BB, like on Github. That would make sense to me. Devs able to merge into their own repo and do a PR across to the main repo, but I see no forking interface within BB.

Is it possible to achieve this?

Cheers,

Lee

-- edit - i found the forking interface so giving that a go. Suggestion to Atlassian that it might be worth adding the fork function near the clone button on the repo's main page or via the ... menu which is where I thought it obvious to look, not in some global, visually unrelated, menu to the left.

[Lee Noble · Accepted solution]

Ok, after finding the forking interface, I think I've worked out a procedure that doesn't diverge too far from established practice. Bob will fork the main project and merge to his master branch, resolving conflicts locally, them initiate the pull request across to the main repo. The merge within BB shouldn't cause a conflict so it's just a matter of clicking a button.

They'll still be able to deploy to staging branches on the main repo before getting the admin involved in a code review.

If I had a request to make of Atlassian, it would be to make SourceTree handle pull requests. The plan is for the dev to have two remotes, one to the main repo and one to their fork. When they come to push to the main repo the Sourcetree should offer to make a pull request, or at least provide a link to BitBucket to make the pull request, and then when approval has been granted SourceTree should be able to recognise that approval has been given (presumably via some API to BB) and allow the push to that remote too.