Forking a repository is similar to copying a repository, with two major differences:
- You can use a pull request to suggest changes from your user-owned fork to the original repository in its GitHub instance, also known as the upstream repository.
- You can bring changes from the upstream repository to your local fork by synchronizing your fork with the upstream repository.
You can fork a repository to your personal account or any organization where you have repository creation permissions. For more information, see "Roles in an organization."
If you have access to a private repository and the owner permits forking, you can fork the repository to your personal account or any organization on GitHub Team where you have repository creation permissions. You cannot fork a private repository to an organization using GitHub Free. For more information, see "GitHub's products."
If you're a member of a enterprise with managed users, there are further restrictions on the repositories you can fork. Managed users cannot fork repositories from outside of the enterprise or fork internal repositories. Managed users can fork private repositories owned by organizations in the enterprise into other organizations owned by the enterprise, or as a fork owned by the managed user. For more information, see "About Enterprise Managed Users" in the GitHub Enterprise Cloud documentation.
You can use GitHub Desktop to fork a repository. For more information, see "Cloning and forking repositories from GitHub Desktop."
Deleting a fork will not delete the original upstream repository. You can make any changes you want to your fork—add collaborators, rename files, generate GitHub Pages—with no effect on the original. You cannot restore a deleted forked repository. For more information, see "Restoring a deleted repository."
In open source projects, forks are often used to iterate on ideas or changes before they are offered back to the upstream repository. When you make changes in your user-owned fork and open a pull request that compares your work to the upstream repository, you can give anyone with push access to the upstream repository permission to push changes to your pull request branch (including deleting the branch). This speeds up collaboration by allowing repository maintainers the ability to make commits or run tests locally to your pull request branch from a user-owned fork before merging. You cannot give push permissions to a fork owned by an organization.
Private forks inherit the permissions structure of the upstream or parent repository. This helps owners of private repositories maintain control over their code. 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. Only team permissions (not individual permissions) are inherited by private forks.
If you want to create a new repository from the contents of an existing repository but don't want to merge your changes to the upstream in the future, you can duplicate the repository or, if the repository is a template, you can use the repository as a template. For more information, see "Duplicating a repository" and "Creating a repository from a template".