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"
Related
Is there a way for me to invite a contributor, allow him to fork from my project and submit a Pull Request, without being able to commit and Push directly into the repository ?
I am new to this, I'm doing some testing and it seems that it should be an easy way to accomplish this, but I cannot find it. I have two accounts and it seems that I can just delete and modify anything in the repository, from the collaborator (guest) account, with no restrictions and moderation from the owner account.
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)
I've transfered ownership of one of my github repositories (rdmuller/docToolchain) to an organisation (docToolchain/docToolchain).
So far, so good. All old URLs are redirected to the new location. Perfect.
But how do I now fork this repository? I fear that, if I fork it, a fork with the name of the old repository (rdmueller/docToolchain) will be created and the redirect will be broken this way...
how can I avoid this?
So, I guess I found a workaround.
suppose you have a repository
user1/repo1
You now want to transfer ownership to org1 and create a fork of it in your account user1.
The problem is that, if you create this fork directly, there will be again a repo called user1/repo1 and github is not able to redirect URLs to the old repository to org1/repo1
Solution:
transfer ownership from user1/repo1 to org1/repo1
create a temporary organisation org2
fork org1/repo1 to org2/repo1
rename org2/repo1 to something like org2/repo1-fork
transfer ownership from org2/repo1-fork to user1/repo1-fork
this seems to do the trick.
Since May 2020, Ben Balter (Senior Product Manager working on Community and Safety at #GitHub) mentions in his tweet:
We're beta testing a new GitHub feature that allows you to invite someone to manage your open source projects in the event that you are unable able to do so yourself.
If you'd like early access, reply or DM with your GitHub handle and I can add you.
See "Maintaining ownership continuity of your user account's repositories"
You can invite someone to manage your user owned repositories if you are not able to.
We recommend inviting another GitHub user to be your successor, to manage your user owned repositories if you cannot. As a successor, they will have permission to:
Archive your public repositories.
Transfer your public repositories to their own user owned account.
Transfer your public repositories to an organization where they can create repositories.
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.
I have one collaborator in my private github repository. After she sent me a pull request, she could actually go to the pull request screen and executed a merge i.e. she had the privilege to merge her changes into my branch.
Is there some kind of setting that I need to set in order to make sure only I can do the merge? And, I don't think this is because my repo is private, right?
Thanks.
From 'https://help.github.com/articles/defining-the-mergeability-of-pull-requests/':
You can require pull requests to pass a set of checks before they can be merged. For example, you can block pull requests that don't pass status checks. You can also require that pull requests have at least one approved review before they can be merged.
By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch. But as your project matures and stabilizes, you can choose to enforce restrictions on how a pull request is merged into your repository.
Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. These branches can also be protected by requiring pull requests to have at least one approved review before they can be merged.
You could use a service like PullApprove or required code reviews to ensure that you have to give permission first.
The "Manage multiple clients" GitHub help page mentions:
This approach lets you retain control over the repos, but still gives your clients access to them.
In many cases it is the cheapest route overall, though you will be stuck paying the bill yourself (unless you bill it to the client).
To use this strategy, upgrade your personal or org account to a paid plan.
Now you can add private repos for the client directly to this account.
If the client wishes to access the repos directly, they can create a free personal account and you can add that user as a collaborator (if the repos are on your personal account) or to a team (if the repos are on an org account).
With an org account you can also give them admin access to the repo if you wish.
So if your project was part of an org account instead of a personal account, you could have the choice the the admin access for the users you add as collaborator.