How do I limit a user's access to only the Release branch

[david_alessio]

I'd like to create a Release branch and grant the customer access to that branch only.  How should I do this?

[Daniil Penkin]

Hello @david_alessio,

If you mean restricting read access for some branches, this is unfortunately not possible: the minimal entity for permissions is repository. So if someone has read access to the repo, they can access files at any of its branches, clone it to the local machine, etc.

What you can restrict for a given branch is who can modify it (e.g. push changes to that branch) – this is configured with branch permissions.

Hope this helps. Let me know if I misunderstood your question.

Cheers,
Daniil

[david_alessio]

Hello @Daniil Penkin ,

Thanks, that's what I see. 

So my question becomes, what's the easiest [standard?] way to create a shared area where a customer has access to released code drops?  If the answer is a separate repo, then how do we manage updating that repo with commits to the Release branch of our development repo?

Regards,

-david

[Daniil Penkin]

Hm, I don't think there's a straightforward answer. This depends on what is the purpose of such shared area, that is what kind of actions/interaction you expect to happen in there.

For instance, if the goal is just to provide source code of the product releases and hiding all the internal dev work, I'd suggest to build some artifacts/distributions and share them instead (you can set this up in Bitbucket). There's no way to partially hide a repository.

If you actually want to share a repository, not the distros, then I believe something like this is possible:

• The main repository (let's call it upstream) is visible to your customer. It contains only one branch – Release.
• The dev repository is a fork of the upstream. When you want to share something with the customer, you can open a PR against upstream and merge it. Note that all commits introduced by that PR to the upstream will become visible to the customer.
• I believe this will create some side effects, potentially annoying for devs: the upstream will be preselected as destination repo in the create PR form by default, so you'll need to be careful to not to share something by a mistake.
• It's probably worth to configure branch restrictions in the upstream so that no new branches can be created and no changes can be introduced without a PR.

I'm not totally sure about this set up, please try it out first if you decide to go this way.

Let me know if this makes sense, or please elaborate what you're trying to achieve in more details otherwise.

Cheers,
Daniil