# Forks

Understand how forks enable independent collaboration by creating separate repositories connected to the original, with distinct settings and permissions.

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 GitHub, the upstream repository is indicated below the name of the fork.

## What makes forks distinct from branches

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

## Which repositories can be forked?

Vous pouvez dupliquer (fork) un référentiel privé ou interne sur votre compte personnel ou une organisation sur GitHub où vous disposez d’autorisations pour créer des référentiels, à condition que les paramètres du référentiel et vos stratégies d’entreprise autorisent la duplication.

En règle générale, vous pouvez dupliquer n’importe quel dépôt public sur votre compte personnel ou sur une organisation où vous avez l’autorisation de créer des dépôts.

Repository, organization, and enterprise policies can limit whether repositories can be forked and where forks can be created. For private and internal repositories, access to forks also depends on repository visibility, organization membership, and administrator settings.

See [Gestion de la stratégie de duplication pour votre organisation](/fr/enterprise-server@3.21/organizations/managing-organization-settings/managing-the-forking-policy-for-your-organization) and [Application de stratégies de gestion des dépôts dans votre entreprise](/fr/enterprise-server@3.21/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise#enforcing-a-policy-for-forking-private-or-internal-repositories).

## Visibility of forks

A fork's visibility is tied to the upstream repository's repository network. Public repository forks are public, and private repository forks are private. Forks of internal repositories are private. You cannot change the visibility of a fork by itself.

All repositories in a repository network share the same visibility setting. A repository network includes the upstream repository, its forks, and forks of those forks. See [Compréhension des connexions entre dépôts](/fr/enterprise-server@3.21/repositories/viewing-activity-and-data-for-your-repository/understanding-connections-between-repositories).

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.

## What happens to forks when a repository is deleted or changes visibility

> \[!WARNING]
>
> * Si vous supprimez l'accès d'une personne à un dépôt privé, l'une de ses duplications de ce dépôt privé est supprimée. Les clones locaux du dépôt privé sont conservés. Si l’accès d’une équipe à un référentiel privé est révoqué ou qu’une équipe ayant accès à un dépôt privé est supprimée, et que les membres de l’équipe n’ont pas accès au référentiel via une autre équipe, les duplications privées du référentiel sont supprimées.
> * Quand la [synchronisation LDAP est activée](/fr/enterprise-server@3.21/admin/managing-iam/using-ldap-for-enterprise-iam/using-ldap#enabling-ldap-sync), si vous supprimez une personne d'un dépôt, celle-ci perd l'accès, mais ses duplications ne sont pas supprimées. Si la personne est ajoutée à une équipe ayant accès au référentiel d’origine de l’organisation dans les trois mois, son accès aux forks sera automatiquement rétabli à la prochaine synchronisation.
> * Vous êtes chargé de veiller à ce que les personnes qui ont perdu l'accès à un dépôt suppriment toute information confidentielle ou propriété intellectuelle.
> * Les personnes ayant des autorisations d’administrateur sur un dépôt privé ou interne peuvent interdire les forks de ce dépôt, et les propriétaires de l’organisation peuvent interdire les forks de tout dépôt privé ou interne au sein d’une organisation. Pour plus d’informations, consultez « [Gestion de la stratégie de duplication pour votre organisation](/fr/enterprise-server@3.21/organizations/managing-organization-settings/managing-the-forking-policy-for-your-organization) » et « [Gestion de la stratégie de duplication pour votre référentiel](/fr/enterprise-server@3.21/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-forking-policy-for-your-repository) ».

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

| Action                                    | Effect on forks                                                            |
| ----------------------------------------- | -------------------------------------------------------------------------- |
| A private repository is deleted           | Its private forks are also deleted.                                        |
| A public repository is deleted            | An active public fork becomes the new upstream repository for the network. |
| A public repository is made private       | Its public forks stay public in a separate network.                        |
| A private repository is made public       | Private forks stay private but disconnect into separate private networks.  |
|                                           |                                                                            |
| An internal repository changes visibility | Forks owned by organizations or personal accounts remain private.          |
|                                           |                                                                            |

Changing a public repository to private can also affect stars, watchers, dependency graph, Dependabot alerts, and code scanning availability. Review repository visibility settings carefully before changing them.

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 [Activation de l’accès en lecture Git anonyme pour un dépôt](/fr/enterprise-server@3.21/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/enabling-anonymous-git-read-access-for-a-repository).

## Permissions of forks

Les duplications privées héritent de la structure des autorisations du dépôt situé en amont. Cela permet aux propriétaires de référentiels privés de garder le contrôle sur leur code. Par exemple, si le référentiel situé en amont est privé et accorde un accès en lecture/écriture à une équipe, cette même équipe bénéficiera d’un accès en lecture/écriture à toutes les duplications du référentiel privé situé en amont. Les duplications privées héritent uniquement des autorisations d’équipe (et non des autorisations individuelles).

> \[!NOTE]
> Lorsque vous modifiez les autorisations de base pour une organisation, les autorisations pour les duplications privées ne sont pas automatiquement mises à jour. Pour plus d'informations, consultez [Définition des autorisations de base pour une organisation](/fr/enterprise-server@3.21/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/setting-base-permissions-for-an-organization#about-base-permissions-for-an-organization).

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 [Allowing changes to a pull request branch created from a fork](/fr/enterprise-server@3.21/pull-requests/how-tos/work-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork).

### Push rulesets for forked repositories

Les règles de poussée s’appliquent à l’ensemble du réseau de fourche d’un référentiel, ce qui garantit que chaque point d'entrée vers le référentiel est protégé. Par exemple, si vous fourchez un référentiel dont les règles de poussée sont activées, les mêmes règles de poussée s'appliqueront également à votre référentiel fourché.

Pour un référentiel fourché, les seules personnes ayant des permissions de contournement pour une règle de poussée sont celles qui ont des permissions de contournement dans le référentiel racine.

See [À propos des ensembles de règles](/fr/enterprise-server@3.21/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets#push-rulesets).

### Important security considerations

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.
* Removing someone's access to the upstream repository does not always delete forks in other organizations.
* Commits can remain accessible in the repository network 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 an 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.

### Forks within an enterprise

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.