We have a repository in GitHub. We want a group of developers to be able to view and fork this repository. But we'd like to prevent them from committing to our branches. Instead, we want this group of developers to fork the repo and create pull requests to contribute. Is there any way to achieve this in GitHub?
Access control is no longer available for private repositories. Both read and write access is given to the collaborators.
If a collaborator will have only read access to a repository, you must create an organization.
You need to add collaborator to your repository and give them just read access, look following article:
https://help.github.com/articles/adding-collaborators-to-a-personal-repository/
Related
We have hired a 3rd party to work on a project, we started by not creating any Repo on our Github, but they started with their Repo. So now it's time to transfer the repo. However, in order to transfer the repo, the developer is asking permission to create a Repo in our Org... but as far as I know, I can only invite him first as a collaborator, a member, before he can create any private repo in our Org... that means he can see our other repo...
I couldn't find any good answer online, please help. Thanks!
Have you tried using Github's Organization features? You can create an organization with your team members in it, and control who has access to what.
Here's a Github page that explains a bit more about how it works.
Do not add them as a member to your Org! (this is the only option today from Github, nor owners...of course). If you do so, this will give your external developer access to all of your repos.
The only way I found you can safely invite an external user is to create a Repo first, then add them in that Repo. By doing that, they will be invited only to that repo, and have no access to the others.
This is my workaround. If you have a better solution, please do comment. I am curious how the "transfer" feature works.
I am now building portfolio to get my first tech job. I would like for any recruiters/potential employers to see my code in case they want to see how I am putting things together but I don't want anyone to be able to fork or copy my work.
How is this possible?
If I have a private GitHub repo does that mean that you can see the repo but just not the inner contents? I have looked at the GitHub documentation already.
If I have a private GitHub repo does that mean that you can see the repo but just not the inner contents?
If you can access a repository (public or private), that means you can read its content and/or clone it (and read its content locally)
You would need to setup a private repository dedicated to show your file
names, meaning a collection of files with:
dummy content
the exact names and folder structure than your actual projects.
That way, you can share to select collaborator access to that "showcase" repository, without compromising the sensitive content of your actual project repositories.
Let's say there is a repository foo/bar which I forked to me/custom-bar. How do I check programmatically (API call maybe?) given foo/bar that there exists a fork that I own from this upstream? Currently, GitHub has the repos/owner/id/forks API endpoint that returns upto 100 entries if you explicitly mention it. I don't see any parameters for creating a custom query for this particular problem. Counting in the rate-limiting and stuff, I don't think it's possible to know this using this API endpoint if I had say a fork of the linux project where over 20k+ forks exist. Is there any fast and efficient way to know this?
Note: I don't want to use authentication if at all possible.
New option (June 2022), directly on GitHub (instead of locally through API)
The repository fork button now displays existing forks
A dropdown has been added to the Fork button to help you quickly find your forks of a repository. This includes forks in your personal account and in organizations that you're a member of.
This feature was inspired by Refined GitHub – an impressive open source project maintained by #fregante.
The feature was requested of GitHub through the GitHub Stars program.
Read more about forking a repository in the GitHub documentation.
We appreciate feedback on this and other topics in GitHub's public feedback discussions.
As a workaround... you can always try to fork your own repo (POST /repos/:owner/:repo/forks).
As explained in "Is it possible to 'fork a fork' in Github?", that won't be generally possible (for a sigle non-organization account) to do if your own repo is itself a fork.
A solution here will be:
Check your repositories using GET /users/:username/repos
For each repo which fork property is true, GEt repository information using GET /repos/:owner/:repo
Check the parent object in json response (that contains parent folder of fork) and validate if full_name is your foo/bar repo
I want to fork a github project to fix a couple of issues and then send a pull request.
The problem I'm running into is that I've already forked the project to adapt it for another user base.
Is it possible to create a second fork? If so, how?
When I try to fork now it just takes me to the previously created fork.
There is no way to have two forks of the same GitHub project unless you use two different GitHub accounts.
So:
Create a separate GitHub account (and verify the email)
Fork the
project
Invite your main GitHub account as a "Collaborator" (from
the settings)
You may need to add the extra step of creating an organization with the new GitHub account and inviting your main github account as an owner of the organization (also make sure your new fork is in that new organization). This will let you do things like deploy automatically to a Heroku app that is connected to your main GitHub account.
Why can't we just have multiple forks???
I mean that I could just commit and push without making a pull request, but I want to do it the offical way and I want somebody else to review the changes before I push to a public project.
GitHub pull requests do not need to be submitted from a fork; they work within a single repository as well:
Pull requests are especially useful in the fork & pull model because they provide a way to notify project maintainers about changes in your fork. However, they're also useful in the shared repository model where they're used to initiate code review and general discussion about a set of changes before being merged into a mainline branch.
There's nothing stopping you from creating a pull request even if you don't technically have to. This is often considered a best practice, and GitHub's own Flow model is largely based on pull requests.
Creating a pull request within a single repository is very similar to creating one from a fork:
Create a feature branch and push your work to that branch on GitHub
In the GitHub web UI, switch to your feature branch
Click the "Compare" & review button
The trick is not to use the master branch to create pull requests. Then you won't need to create multiple forks since you can make as many branches as you need and make pull requests against each branch independently.
Given a clean forked repo, create a dedicated branch and use that branch for the pull request.
You can create branches from the web UI (although it is not obvious).
Click the branch selection dropdown, type the new branch name in the input field, and then you'll see a clickable link Create branch: <new-branch-name> as shown below. The tricky UI part is that it might not be very obvious you should click the "create branch: xyz..." — it is NOT displayed as a button or as a hyperlink, and there is NO indication that this is a clickable link. Moreover, there is NO hint whatsoever that a branch can be created until you type in the search box — anyone would probably assume that the search box is used exclusively for searching branches, and not for creating them.
In case you already made changes directly in your fork's master branch then consider moving those changes into a dedicated branch and hard resetting the master branch to the original remote so that you keep it clean for synching with the upstream repo.
See also:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository
The best way, recommended by github manual, is use command line git, mirror clone your repo and push it to your github.
https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/duplicating-a-repository
If you strongly prefer GitHub web interface to the command line, a GUI friendly workaround is create a new organization and fork to that new organization.
Another GUI way I can think of is to declare a fork as a template repo using repo's setting so you can create as many forks as you need.
We need to have a read only github repo that mirrors our main branch.
I've noticed castle have managed to do it with their entire collection of repositories.
How would I go about achieving this?
Castleproject is an organization (also mentioned here) in order to restrict write access.
That is why you see read-only addresses on their projects.
That also means it (ie the organization "castleproject") can add users with read-only rights.
As a simple user owning a GitHub repo, you wouldn't have access to that feature.
You need to define an "organization".
I believe this is what you are looking for right here:
http://justcramer.com/2011/05/09/creating-a-one-way-git-server-mirror/