I'm very, very excited about this. The poor level of control over permissions in orgs were a big issue when we (LXQt) moved our development to Github. Look forward to trying it out.
The new collaborator feature makes it easier to include stakeholders in the communication loop.
The feature I really think github is lacking right now is the ability to give selective permission to some sections of the repo (issue|wiki|code|releases). Right now the only way to share issues but not the code is to create a separate repository, which is cumbersome to do and maintain for every project.
I can't overstate how useful it would be to at least restrict write access to certain branches. Bitbucket has had it for a while now [1], so I'm surprised GitHub haven't followed suit.
I don't know if I would use branch restriction, it sounds like an anti pattern for the git philosophy (SVN file locks, anyone?). Why would I commit to someone else's branch, unintentionally? I think that a "gentlemen’s agreement" as your link states, is more than enough. Can you provide a use case where this feature is useful? Do you use it often in your workflow?
I can see it being used for autodeployments on a "stable" branch and no deployments on other develop branches, and the stable branch being write-restricted.
7 comments
[ 2.8 ms ] story [ 27.7 ms ] threadEdit: Here are in-depth docs on the new features: https://help.github.com/articles/improved-organization-permi...
The feature I really think github is lacking right now is the ability to give selective permission to some sections of the repo (issue|wiki|code|releases). Right now the only way to share issues but not the code is to create a separate repository, which is cumbersome to do and maintain for every project.
[1]: https://blog.bitbucket.org/2013/09/16/take-control-with-bran...