Improved organization permissions

Post by scrollaway » Wed, Jun 10, 2015, 5:05 PM UTC

Post by scrollaway » Wed, Jun 10, 2015, 5:47 PM UTC

itajaja wrote: post #3

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.

Post by itajaja » Wed, Jun 10, 2015, 8:35 PM UTC

nathankleyn wrote: post #5

itajaja wrote: post #3

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. [1]: https://blog.bitbucket.org/2013/09/16/take-control-with-bran...

Post by sytse » Thu, Jun 11, 2015, 12:16 PM UTC

scrollaway wrote: post #7

itajaja wrote: post #6

Earlier quoted context omitted.

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.