Branch permissions (BB-6761)

Issue #5554 resolved
Daniel Falk
created an issue

Using topic branches and doing pull requests creates considerable clutter. Well documented here:

That article says that the solution is "auto close branch", but that only works when you're all working off the same repository. Otherwise auto-close doesn't seem to be available.

I can't work around this by having everyone in the same repository because there are no branch level permissions. See this bug report, where the "wontfix" rationale is that you can just use forks:

Fixing either issue would solve the problem as far as I'm concerned. Allow auto-close everywhere, or give us branch level permissions.

Comments (107)

  1. Tronik

    +1 for branch level permissions. We have a production branch that is used by our build server to deploy. Our team is getting bigger and we would like to lock commits to this branch down.

  2. Kyle Cordes

    "Me Too!" - please give us branch level permissions. Approximately once a week we have to do various hackery to undo something that happened, which would not have happened if we had branch level permissions.

  3. Jelmer

    +1 @Atlassin perhaps it is smart to add a vote-up possibility in the issue tracker? To prevent people from saying just "+1" in the comment section ;-)

  4. ryan_hunter

    If you dont want to provide granular permissions in bitbucket because it collides with Stash, why not just migrate bitbucket to become a cloud hosted stash?

  5. Abettor

    Absolutely must have feature, it will give bitbucket competition advantage over github:) And guys, stop +1 and just VOTE (in the top of the page, right side)

  6. Justen Stepka

    We've released branch restrictions which can be configured via the repository admin "Branch management" screen.

    Thanks for your patience everyone, we've released this ASAP. We'll have a blog and documentation detailing the specifics in a week -- we didn't want you to wait another minute for this one!

  7. Martin Geisler

    @ptm_patrickt and @Danny Rodriguez : Mercurial and Git doesn't have a concept of limiting read access more narrowly than on a per-repository basis. If you have branches you don't want people to read, you have to create a separate repository for them and limit read-access on that repository.

    You might then be able to use the branch permission system to prevent accidental pushes of those branchs to your main repository. Something like saying that branch secret cannot be pushed by anybody to the main repository. That would leak the branch name, but that might be acceptable.

  8. Martin Geisler

    @ptm_patrickt To put it differently, if Bitbucket should add support for limiting read access to certain branches, I believe they would have to do it by effectively maintaining two repositories behind the scenes: one with all branches for those who are allowed to read them, and one with a subset of the branches for those who cannot read everything.

    They could of course do pretend that there is just one repository in the web interface and do fancy things for Git/Mercurial push and pull, but I don't think it's worth the effort.

  9. AdrienBerthou

    @Martin Geisler From what I read, Git does not support from branch level permissions (just to say that it's not about limiting read access only).

    So I doubt bitbucket would ever provide this feature :( There seems to be a few work arounds for GIT hosted repos though, but then forget about bitbucket (which our team want to keep using...hence we won't switch), see

  10. Ryan H Becker

    I'm confused about what's getting up-voted at this point. Branch-level permissions were implemented a while back. Is the subsequent voting about offering read-restrictions per branch? If so, I think a new issue should get created for that, as the original ask has been satisfied. Maybe I'm misunderstanding.

  11. Trey Howard

    I would like the ability to block specific developers from committing to specific branches while allowing other developers to commit to that branch. For example, prevent John from committing to master but allow Jane to commit to master. Does current functionality support this?

  12. Ramón López

    RH Becker wrote: "Is the subsequent voting about offering read-restrictions per branch?"

    I don't know others, but that's EXACTLY the reason I've been watching this issue (and looking forward for it's resolution) for a long time. But, at this point, I can see why counting with a separated new issue only for covering that "read-restrictions" aspect would be more convenient as well, and if so... it will have my up-vote :)

  13. William Archer

    Guys, seriously. Get this together. This is basic stuff. I need to be able to have a configured branch with all my production keys and stuff set up that is both saved out to source control and not available to the whole team.

  14. Log in to comment