Forks are repositories that start as copies of another repository, called the upstream repository. A fork has its own settings and permissions but stays connected to the upstream repository.

When you view a forked repository on {% data variables.product.github %}, the upstream repository is indicated below the name of the fork.

A branch is part of one repository. A fork is a separate repository with its own settings and collaboration space.

Each fork can have its own:

• Branches
• Members and discussions
• Issues and pull requests
• Actions and projects
• Tags, labels, and wikis

{% data reusables.repositories.you-can-fork %}

Repository, organization, and enterprise policies can limit whether repositories can be forked and where forks can be created. For private{% ifversion ghec or ghes %} and internal{% endif %} repositories, access to forks also depends on repository visibility, organization membership, and administrator settings.

{% ifversion fpt or ghec %}

If you're a member of an {% data variables.enterprise.prodname_emu_enterprise %}, additional restrictions apply to the repositories you can fork. {% ifversion ghec %}{% data reusables.enterprise-accounts.emu-forks %}{% endif %} See AUTOTITLE{% ifversion fpt %} in the {% data variables.product.prodname_ghe_cloud %} documentation.{% else %}.{% endif %}

{% endif %}

See AUTOTITLE{% ifversion fpt %}.{% else %} and AUTOTITLE.{% endif %}

A fork's visibility depends on the upstream repository. Public repository forks are public, and private repository forks are private.{% ifversion ghec or ghes %} For internal repositories, the visibility of a fork depends on its owner: a fork owned by an organization is internal, while a fork owned by a personal account is private.{% endif %} You cannot change the visibility of a fork by itself.

A repository network includes the upstream repository, its forks, and forks of those forks. Repositories in the network share Git data and remain connected to the upstream repository. See AUTOTITLE.

Deleting a repository or changing its visibility can affect the network. If you delete a fork, code contributions from that fork can remain accessible to the repository network.

{% data reusables.repositories.deleted_forks_from_private_repositories_warning %}

Visibility changes can separate forks into new repository networks so that existing fork owners can keep working without unexpected loss of access.

Changing a public repository to private can also affect stars, watchers, dependency graph, {% data variables.product.prodname_dependabot_alerts %}, and {% data variables.product.prodname_code_scanning %} availability. Review repository visibility settings carefully before changing them.

{% ifversion ghes %} If a public repository has anonymous Git read access enabled and the repository is made private, all of the repository's forks lose anonymous Git read access and return to the default disabled setting. If a forked repository is made public, repository administrators can re-enable anonymous Git read access. See AUTOTITLE. {% endif %}

{% data reusables.repositories.private_forks_inherit_permissions %}

Public forks do not inherit the permissions structure of the upstream repository. Fork owners control access to their forks, but repository networks still share Git data. Commits pushed to any repository in a network can be accessible from other repositories in that network, including the upstream repository.

When you fork a public repository to your personal account, you can allow maintainers of the upstream repository to push to your pull request branch. This can help maintainers update your branch, run tests, or resolve small issues before merging. You cannot give push permissions to a fork owned by an organization. See AUTOTITLE.

{% data reusables.repositories.rulesets-push-rulesets-fork-network-information %}

See AUTOTITLE.

Forks are powerful collaboration tools, but they can expose code and history in ways that are easy to overlook.

• Forks have their own permissions separate from the upstream repository.
• Owners of an upstream repository can read all forks in the repository network.
• Organization owners may have administrative access to forks created in personal namespaces.
• Organization owners of a repository that has been forked have read permission to forks created in organizations, but do not have the ability to delete the fork or its branches.
• Forks created in another organization will not be deleted when individual access is removed from the upstream repository.
• Git data from any repository in a network may be accessed from any repository in the same network, including the upstream repository, even after a fork is deleted.

Before allowing forks for sensitive work, review the permissions and visibility model for your repository or organization.

Forks within the same organization copy collaborator and team settings from the upstream repository. The organization controls permissions for these forks, and existing visible teams may keep access.

Internal repositories support a single level of forking. You cannot fork a private fork of an internal repository. This keeps access and management simpler for repositories that are visible across an enterprise.