GitLab does not seem to allow to restrict access for developers to push to branches “owned” by other developers.
DeveloperA (usera) creates and pushes the branch usera/work
DeveloperB (userb) creates and pushes the branch userb/work.
Neither of them should be allowed to push changes to the others branch.
This is something we have been able to restrict using Gitolite.
If not possible, we then see using Forks might be the solutions here. Developers have their own forks with their work branches, instead of the main repository.
I’m pretty sure mine works this way. I set myself up my own project under my own userid and in Settings → General → Visibility, project features, permissions I have it set to Internal. You can also set View and Edit files to only Project Members. I could invite one of my other users to my user project and then set his permissions appropriately, eg: Reporter or Guest even. There is also the option for General → Repositories → Protected Branches - of which I could set it to Maintainers, for whichever branches I have, and thus, if the members are Developers or lower, then they aren’t going to be able to push to my protected branches.
I think that some or even all of that would do what you want, unless I’m missing something here from what you are attempting to do? By default my master branch on my user project is already protected. For other branches, when they are created for example “work”, then it’s just a case of going into this option and protecting it, for the level of users who can or cannot push code to it. Perhaps that would then enforce the PR to be accepted from project members who don’t have the rights to automatically push otherwise.
The projects is not in user space, but internal groups.
We could with GitLab EE, create protected branches for each Project Member for only them to allow push to branches that matches their username. That though is a lot of configuration work. We have 400+ repositories.
However we could probably script it, and then configure it through the GitLab API.
However every time we add a Member, we then need to also add that user to Protected Branches configuration.
Yep understand. For our internal groups, I’ve assigned the rights at group level, and then added each project to it, with users either reporter, developer, maintainer. I don’t have a load of users, only 10. And the branches protected to maintainer level so that Developers or lower couldn’t push. But I expect you have much more a complicated requirement to be able to set it at group level for all projects. Ours is probably much more simpler in comparison because our team is much smaller.
I know that in terms of permission levels, especially for CE is limited in comparison to EE with purchased subscriptions, so not really sure how else to do something like that other than how I mentioned at user project level, or set at group level. And then if you want an individual requirement for access to a project, to override it from the group level by setting the member rights at project level.
Assuming if that is the case, API would probably be easier than manually doing it, especially if you have a more complicated rights-assignment than my example from our small installation
We have aprox 50 developers, and 400+ repositories.
Currently we are using Gitolite, but have had GitLab in our sights for years now, and finally gotten ready to migrate to it. We will go for the On Premise GitLab Enterprise Premium.
There is not much configuration possible at group level to restrict access.
You can set:
So after all this discussion what ended up being the recommended method? We have a single project, multiple branches, each branch should be writable/readable by only a subset of users. They should be able to make their own branches that are only editable by themselves, preferably with a set prefix to keep everything tidy. How is it done?
