When a user is removed from the organization, they will lose access to private forks of your organization’s private repositories, but may still have local copies. However, they cannot sync local copies with your organization’s repositories. See https://help.github.com/en/articles/removing-a-member-from-your-organization
Their private forks can be restored if the user is reinstated as an organization member within three months of being removed from the organization. See https://help.github.com/en/articles/reinstating-a-former-member-of-your-organization
- If it's a private repository, all of its private forks will be deleted as well.
- If it's a public repository, one of the existing public forks will be chosen to become the new parent.
Private forks inherit the permissions structure of the upstream or parent repository. For example, if the upstream repository is private and gives read/write access to a team, then the same team will have read/write access to any forks of the private upstream repository. This helps owners of private repositories maintain control over their code.
Team permissions are not added to a fork if the forking user is an external collaborator and not a member of the organization. - For outside collaborators, the org owners can set permissions levels for them - which would restrict or enable the ability to 'share' forks: https://help.github.com/articles/adding-outside-collaborators-to-repositories-in-your-organization/
Since the forks of org-owned repos are also owned by the org regardless of who forked them, the forks should have the same permissions -- so the member who forked will not be able to add an outside collaborator to their fork or allow non-org members to fork it unless they are an admin or owner in the org
GitHub advocates a branch-and-merge strategy over a fork-and-pull usage pattern, as GitHub Enterprise is able to optimize branch operations and storage. Fork-heavy repositories with large object and file sizes must deal with the multiplying effects of (possibly) large fork networks on storage and performance. If fork-and-pull is the operational model of a particular team, and that repository is nearing the 1GB guideline, considerations should be made with regard to the object size of the source repository. The max object size we would recommend for a repository utilizing a fork-and-pull model is around 10MM objects.
Can I allow forks within the organizaion but disallow private forks to travel outside the organization?
There’s no way to restrict forks like this today. Forking private repos is off by default, but if you turn them on you can’t prevent where they’re forked.
No, the organization level settings serve as a policy for the repository level settings.
- Forkable when allowed? Yes
- Forkable when disallowed at repo? You will not have the option to disallow forking for a public repo.
- Forkable when disallowed at org level? Yes
- Forkable when allowed? Yes
- Forkable when disallowed at repo? No
- Forkable when disallowed at org level? No
- Forkable when allowed? Yes
- Forkable when disallowed at repo level? No
- Forkable when disallowed at org level? No
- Fork a repo
- About forks
- Forking projects
- Reinstating a former member of your organization
- What happens to forks when a repository is deleted or changes visibility?
- Allowing people to fork private repositories in your organization
- Allowing people to fork a private repository owned by your organization
- What the fork!
- 'Fork' discussions on GitHub Community