Is there a way to know which people have merge privileges on a public GitHub repository. If the owner is a user and not an organization, then at least I know one maintainer, but it's possible that there are other users with merge rights. Also, if the owner is an organization it is possible, that not all members of the organization have merge rights. So is there a way to find the exact maintainers?
Team privileges are not public in general. Even an organization-membership is not public since the publicity must be chosen by the given member, as the Documentation states:
,,By default, your organization membership visibility is set to private. You can choose to publicize individual organization memberships on your profile."
This partly applies for their implementation of CODEOWNERS, too. If it is up to date the given source file is annotated with a link to its responsible GitHub user.
However there's normally no need to know the individual maintainers of a repository (since every interaction with repos you're able to access is covered by the GitHub UI, which also assures that somebody takes care about your request). If your attention is about a public repository you might search the commits for accepted pull-request. But in that case you would preferably fork the repo and just generate pull-requests on your own.
You are even not able to contact an organization via GitHub - try to find their official website, contact them and ask for their maintainers if you need that information.
GitHub (since July 2017) now officially supports "code owners" for projects. Code owners are individuals or teams that are responsible for code in a repository.
Project maintainers can add a CODEOWNERS file to their repository to make it easier for others to identify code owners and have code owners be notified to review Issues and Pull Requests.
See the announcement post and help article for more info.
Just go to the team members tab within your repo, on the right it will describe what type of member they are. Ex: member or owner.
Related
I have an issue, I have a team (they are added into Github package's teams list with Write perm) of external developers, I want to restrict their ability to approve each other's PRs.
Meaning other team/users should be probably a different set of perms.
How can I do it? I wasn't able to find this on Github.
PS.
I tried adding this to .github/CODEOWNERS (also enabled require owner review)
* #company/company-devs some-special-developer
but #other_company/devs <- were still able to approve
is there a way to limit new repositories creation for all users except for admins in an organization?
I found this article on Github, but this restricts the repository type. I am looking for a way to prevent users to create any new repository, unless an admin in the same organization approved.
Is it even possible with Github?
You were close to the solution. There is actually a link to another section in the documentation you shared named Enforcing repository management policies in your enterprise account with a specific section Enforcing a policy on creating repositories.
There, you'll see that you can choose whether members can create repositories in your organization.
Here is the step related to it:
Is it possible to limit who can create repositories in a Github organization. From this article: https://help.github.com/en/enterprise/2.14/user/articles/restricting-repository-creation-in-your-organization it seems like the options are basically owners or everyone. Is there a middle ground?
Making someone a Github owner is a serious permission so we really don't want to give that out just so that someone can make a repo. On the other hand allowing everyone in the organization the ability (contractors, non-technical, read-only roles) the permission to make repos seems too broad.
Has anyone come up with a better solution for this?
One workaround would be to setup a webhook.
That means having a listener for a repository event, which does include the owner: If said owner is not part of an admin list, the listener could:
send back an email to the owner of the newly created repostory, explaining that creation has been denied
delete the repository (through the GitHub API)
We are setting up a open source project which we would like to allow freelancers to develop alongside us without damaging anything.
In general can the collaborators make changes to repositories without admins being able to check the changes over before code is merged into master.
What is the best method to use to prevent the repository from user damage whilst working with a large number of public freelance developers / users?
What you can do is you can give them read-only permission. They can fork to their own account and start working on that code. Then after finishing a feature they can create a pull request to merge it back to the main repo.
For a Personal account on Github, there are two types of 'roles' - Owner and Collaborator.
For a full list of who can do what - see here:
https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/permission-levels-for-a-personal-account-repository
To answer your question - "No - A collaborator cannot delete a repository"
We have quite a few repositories in our organization, and we are constantly adding more. We also have a few different teams - Superusers, Developers, Contractors, etc. I want every newly created repository to automatically assume default permissions, like Superusers get automatic admin access to the repo, Contractors group gets just read access, etc. Is it possible to set that up? Is there a setting somewhere that I missed? And if there's not a way to do that, is there a way to batch apply a permission for one group to all repos within an account?
Update June 2017: with nested teams, you now can associate permissions to sub-teams, which could help group of users to have the correct right regarding a repo part of the organization.
Original answer (Apr. 2016)
Is it possible to set that up?
I did not see a way through the native GitHub web GUI administration pages.
And "permission" is deprecated when creating a team.
What you could consider though is a webhook listening for a an event, like a repository event.
That script listening to the event could then use the Team API to update the permission of the teams (according to their names) for the newly created repo.