Les forks sont des référentiels qui commencent en tant que copies d’un autre référentiel, appelé référentiel en amont. Un fork a ses propres paramètres et autorisations, mais reste connecté au référentiel en amont.
Quand vous consultez un dépôt forké sur GitHub, le dépôt source est indiqué sous le nom du fork.
Ce qui fait la distinction entre les duplications et les branches
Une branche fait partie d’un référentiel. Un fork est un dépôt distinct avec ses propres paramètres et espace de collaboration.
Chaque fork peut avoir son propre :
- Branches
- Membres et discussions
- Problèmes et pull requests
- Actions et projets
- Balises, étiquettes et wikis
Quels référentiels peuvent être dupliqués ?
Vous pouvez dupliquer n’importe quel référentiel public :
- Vers votre compte personnel
- Vers une organisation où vous avez l’autorisation de créer des référentiels
Si vous avez accès à un référentiel privé et que le propriétaire autorise la duplication, vous pouvez dupliquer le référentiel :
- Vers votre compte personnel
- Vers une organisation sur GitHub Team où vous avez l’autorisation de créer des référentiels
Vous ne pouvez pas dupliquer un dépôt privé vers une organisation en utilisant GitHub Free. Pour plus d’informations sur GitHub Team et GitHub Free, consultez plans de GitHub.
Les stratégies de dépôt, d’organisation et d’entreprise peuvent limiter si les référentiels peuvent être dupliqués et où des duplications peuvent être créées. Pour les référentiels privés , l’accès aux duplications dépend également de la visibilité des référentiels, de l’appartenance à l’organisation et des paramètres d’administrateur.
Si vous êtes membre d’un entreprise avec utilisateurs managés, des restrictions supplémentaires s’appliquent aux dépôts que vous pouvez dupliquer. Consultez À propos de Enterprise Managed Users dans la GitHub Enterprise Cloud documentation.
Voir Gestion de la stratégie de duplication pour votre organisation.
Visibilité des fourches
La visibilité d’un fork est liée au réseau de référentiels en amont. Les forks de dépôts publics sont publics, et les forks de dépôts privés sont privés. Vous ne pouvez pas changer la visibilité d’un fork à lui seul.
Tous les référentiels d’un réseau de référentiel partagent le même paramètre de visibilité. Un réseau de référentiel inclut le référentiel en amont, ses fourches et les duplications de ces fourche. Consultez « Compréhension des connexions entre dépôts ».
La suppression d’un référentiel ou la modification de sa visibilité peut affecter le réseau. Si vous supprimez un fork, les contributions au code de ce fork peuvent rester accessibles via le réseau du dépôt.
Que se passe-t-il pour les forks lorsqu’un référentiel est supprimé ou change de visibilité
Avertissement
- 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.
- 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é 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é au sein d’une organisation. Pour plus d’informations, consultez « Gestion de la stratégie de duplication pour votre organisation » et « Gestion de la stratégie de duplication pour votre référentiel ».
Les changements de visibilité peuvent séparer les forks en nouveaux réseaux de dépôts afin que les propriétaires de forks existants puissent continuer à travailler sans perte d’accès inattendue.
| Action | Effet sur les fourches |
|---|---|
| Un référentiel privé est supprimé | Ses forks privés sont également supprimés. |
| Un référentiel public est supprimé | Un fork public actif devient le nouveau dépôt en amont du réseau. |
| Un référentiel public est rendu privé | Ses forks publics restent publics sur un réseau distinct. |
| Un référentiel privé est rendu public | Les forks privés restent privés, mais sont dissociés en réseaux privés séparés. |
La modification d’un référentiel public en référentiel privé peut également affecter les étoiles, les observateurs, le graphique Dependabot alertsdes dépendances et code scanning la disponibilité. Passez en revue attentivement les paramètres de visibilité du référentiel avant de les modifier.
Autorisations des 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).
Remarque
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.
Les forks publics n'héritent pas de la structure des autorisations du dépôt amont. Les propriétaires de forks contrôlent l’accès à leurs forks, mais les réseaux de dépôts partagent toujours les données Git. Les commits poussés vers n’importe quel dépôt d’un réseau peuvent être accessibles depuis d’autres dépôts de ce réseau, y compris le dépôt en amont.
Lorsque vous forkez un dépôt public vers votre compte personnel, vous pouvez autoriser les responsables de la maintenance du référentiel en amont à envoyer (push) à votre branche de demande de tirage (pull request branch). Cela peut aider les maintenances à mettre à jour votre branche, exécuter des tests ou résoudre de petits problèmes avant la fusion. Vous ne pouvez pas accorder d’autorisations Push à un fork appartenant à une organisation. Consultez « Allowing changes to a pull request branch created from a fork ».
Ensembles de règles de push pour les dépôts forkés
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.
Consultez « À propos des ensembles de règles ».
Considérations importantes relatives à la sécurité
Les forks sont de puissants outils de collaboration, mais ils peuvent exposer du code et de l’historique de manière facile à ignorer.
- Les forks ont leurs propres autorisations distinctes de celles du dépôt amont.
- Les propriétaires d’un dépôt en amont peuvent lire tous les forks du réseau du dépôt.
- Les propriétaires de l’organisation peuvent avoir un accès administratif aux forks créés au sein d’espaces de noms personnels.
- La suppression de l’accès d’un utilisateur au référentiel en amont ne supprime pas toujours les duplications dans d’autres organisations.
- Les commits peuvent rester accessibles dans le réseau du dépôt même après la suppression d’un fork.
Avant d’autoriser les duplications pour le travail sensible, passez en revue les autorisations et le modèle de visibilité de votre dépôt ou organisation.
Bifurcations au sein d’une organisation
Les forks au sein de la même organisation copient les paramètres des collaborateurs et des équipes depuis le dépôt parent. L’organisation contrôle les autorisations pour ces fourches, et les équipes visibles existantes peuvent conserver l’accès.
Branches au sein d’une entreprise
Les référentiels internes prennent en charge un seul niveau de duplication. Vous ne pouvez pas dupliquer un fork privé d’un dépôt interne. Cela simplifie l’accès et la gestion pour les référentiels visibles dans une entreprise.