À propos des autorisations et de la visibilité des duplications

À propos des autorisations pour la création de fourches

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.

Si vous dupliquez un dépôt privé qui appartient à un compte personnel, les collaborateurs externes ont également accès à la duplication. Si vous dupliquez un dépôt privé ou interne qui appartient à une organisation, les équipes au sein de l'organisation ont accès à la duplication, mais pas les collaborateurs externes. Vous pouvez ajouter un collaborateur externe à une duplication d’un référentiel privé appartenant à une organisation si vous êtes propriétaire de cette organisation ou si votre organisation permet aux administrateurs de référentiel d’inviter des collaborateurs externes.

Les organisations peuvent autoriser ou empêcher le fourchage de tous les dépôts privés appartenant à l'organisation, tandis que les entreprises peuvent appliquer des stratégies pour spécifier où les membres peuvent créer des fourches de dépôts privés ou internes. Les stratégies contrôlent les options disponibles pour les organisations de l’entreprise.. Pour plus d’informations, consultez Gestion de la stratégie de duplication pour votre organisation et Application de stratégies de gestion des dépôts dans votre entreprise.

À propos de la visibilité des fourches

Une fourche est un nouveau dépôt qui partage le code et les paramètres de visibilité avec le dépôt amont. Tous les forks de dépôts publics sont publics. Vous ne pouvez pas modifier la visibilité d’un fork.

Tous les dépôts appartiennent à un réseau de dépôt. Un réseau de dépôt contient le dépôt amont, les fourches directes du dépôt amont et toutes les fourches de ces fourches. Toutes les fourches du réseau de dépôt ont le même paramètre de visibilité. Pour plus d’informations, consultez « Compréhension des connexions entre dépôts ».

Si vous supprimez un dépôt ou changez les paramètres de visibilité du dépôt, vous affectez les fourches du dépôt. Pour plus d’informations, consultez Que se passe-t-il avec les duplications quand un dépôt est supprimé ou que sa visibilité change ?

Si vous supprimez une duplication, toutes les contributions de code de cette duplication seront toujours accessibles au réseau de référentiel.

À propos des autorisations des fourches

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).

Les fourches publiques n’héritent pas de la structure d’autorisations du dépôt amont. Si vous dupliquez un dépôt public sur votre compte personnel, apportez des modifications et ouvrez une demande de tirage pour proposer vos modifications au dépôt en amont, vous pouvez donner à toute personne disposant d’un accès push au dépôt en amont l’autorisation d’envoyer (push) des modifications à votre branche de demande de tirage (y compris la suppression de la branche). Cela accélère la collaboration en permettant aux responsables de maintenance du dépôt d’effectuer des validations ou des tests localement sur votre branche de demande de tirage à partir d’une duplication appartenant à un utilisateur avant la fusion. Vous ne pouvez pas accorder d’autorisations d’envoi (push) à une duplication (fork) appartenant à une organisation. Pour plus d’informations, consultez « Autorisation de changements sur une branche de demande de tirage créée à partir d’une duplication ».

Considérations importantes relatives à la sécurité

Si vous utilisez des fourches ou si vous êtes propriétaire d’un dépôt ou d’une organisation qui autorise les fourches, il est important de connaître les aspects de sécurité suivants.

• Les fourches ont leurs propres autorisations qui sont distinctes du dépôt amont.
• Les propriétaires d’un référentiel qui a été fourché ont une autorisation en lecture sur toutes les fourches dans le réseau du référentiel.
• Les propriétaires d’organisation d’un dépôt qui a été fourché ont une autorisation d’administration sur les fourches créées dans les espaces de noms utilisateur personnels, y compris la possibilité de supprimer les fourches et leurs branches.
• Les propriétaires d’organisation d’un dépôt qui a été fourché ont une autorisation en lecture sur les fourches créées dans les organisations, mais n’ont pas la possibilité de supprimer les fourches ou leurs branches.
• Les fourches créées dans une autre organisation ne sont pas supprimées quand un accès individuel est supprimé du dépôt amont.
• Les commits dans n’importe quel référentiel d’un réseau sont accessibles à partir de n’importe quel référentiel du même réseau, y compris le référentiel en amont, même quand une fourche est supprimée.

À propos des fourches au sein d’une organisation

Les fourches au sein d’une même organisation copient les collaborateurs et les paramètres d’équipe de leurs dépôts amont. Si un dépôt appartient à une organisation :

• Cette organisation contrôle les autorisations de ses fourches.
• Toutes les équipes de la structure d’autorisations en amont qui existent et sont visibles dans l’organisation ou l’espace de noms utilisateur cible voient leurs autorisations copiées.
• Les autorisations d’administration restent avec le propriétaire amont, sauf quand un utilisateur crée des fourches dans une autre organisation.
• Si ce dépôt est fourché dans un espace de noms utilisateur, l’organisation conserve les autorisations d’administration et toutes les équipes disposant d’un accès conservent cet accès.