This question is in reference to Atlassian Documentation: Using branch permissions
Recently Bitbucket has changed the branch permissions, so they include the settings for rewrites and branch deletion. Now it is not clear how to nest the permissions anymore. What we want is these settings:
BitBucket Branch Management.PNG
So we want only process reviewers to be able to acces develop and only release managers on master and any release branches. master and develop must never be deleted and no branch must ever be rebased. In the new settings we can set this:
Screen Shot 2016-09-15 at 14.43.12.png
Which is fine except for one potential problem. Doesn't this still allow rewrites on any branch except the three patterns mentioned? And if we add * as a pattern for `everyone`, just to deactivate rewrites, doesn't that overlap and give everyone write access to the branches that should be limited to specific groups?
Hello @Titus Nachbauer,
I think, only the designees (in this case Process_Managers and Release_Managers) would have write access in the scenario you present. See: https://confluence.atlassian.com/display/BITBUCKET/Branch+permissions#Branchpermissions-Branchpermissionsoverlap
If your team only creates release branches with the pattern:
you wouldn't need the "everybody" designation with a general wildcard. I would suggest that your team follow the branch pattern you've established:
Every branch with that pattern will inherit those permissions and not be subject to rewriting.
We are using git flow, so we have a lot of feature branches. Since JIRA creates those branches, they do not start with feature/, so I cannot specifically select those branches except by the pattern *. So your suggestion would not work. The point of my question is that I want to prevent rebases on ALL branches, because rebases can be very evil on shared branches and inexperienced programmers might even rebase by accident. In the old permissions screen this was simple, in the new screen it is actually impossible with the permissions we want. I tested the following:
Broken branch permissions.PNG
This should prevent anyone who is not in the group Release_Managers to delete the branch test-branch-permissions, however, they can just delete it, because the * permission is additive. This is quite useless, especially because the migration to the new screen has automatically set the permissions in this way. Now it seems I will have to go through all of the projects and fix the permissions by hand (and allow rewrites on all but the most important branches).
As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual wo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs