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.
Related
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"
Two partners are building a software project. They want that each change made by one partner must be approved by the other partner.
If one of them opens a GitHub repository and makes the other one a collaborator, then both of them can change the repository without consent from the other partner. They can also ask for consent by doing the change in a branch and then doing a pull-request on the branch, but the system does not force them to do it, so they might forget.
If one of them opens a GitHub repository and does NOT make the other partner a collaborator, then the second partner must make a pull request for each change, but the first partner can still make changes without the other partner reviewing them.
Is it possible to create a repository such that, each change by one of the partners only becomes public after the other partner approves it?
I don't think such feature exists yet in Github AFAIK. But I think something like this works.
Create another account either a dummy or a bot account
Create repository from the dummy/bot account
Since you both are not collaborators, you need to fork the repository and issue pull requests no matter what.
There is a minor correction to what you said though
If one of them opens a GitHub repository and does not make the other partner a collaborator, then the second partner must make a pull request for each change, but the first partner can still make changes without the other partner reviewing them.
If you make your partner a collaborator then he too can push code to master without a pull request.
PS: Honestly, I don't think this question is supposed to be on StackOverflow.
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.
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.