Skip to main content

Enterprise Server 3.15 est actuellement disponible en tant que version finale (RC).

Que se passe-t-il avec les duplications quand un dépôt est supprimé ou que sa visibilité change ?

La suppression de votre référentiel ou la modification de sa visibilité affecte les duplications de ce référentiel.

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 dépôt privé est révoqué ou si l'accès à un dépôt privé est supprimé et que les membres de l'équipe n'ont pas accès au dépôt via une autre équipe, les duplications privées du dépôt sont supprimées.
  • Quand la synchronisation LDAP est activée, 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 dépôt d'origine de l'organisation dans un délai de trois mois, son accès aux duplications est automatiquement restauré à 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 avec des autorisations d'administration sur un référentiel privé ou interne peuvent interdire la duplication de ce référentiel, tandis que les propriétaires de l'organisation peuvent interdire la duplication de tout référentiel privé ou interne dans 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 ».

Suppression d’un dépôt privé

Quand vous supprimez un dépôt privé, toutes ses duplications privées sont également supprimées.

Suppression d’un dépôt public

Lorsque vous supprimez un référentiel public, la fourche publique active la plus ancienne est choisie comme nouveau référentiel en amont. Tous les autres référentiels sont dupliqués à partir de ce nouveau référentiel en amont et les demande de tirage (pull request) suivantes se dirigent vers ce nouveau référentiel en amont.

Duplications privées et autorisations

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

Changement d’un dépôt public en dépôt privé

Si un dépôt public est rendu privé, ses duplications publiques sont séparées dans un nouveau réseau. Comme pour la suppression d’un référentiel public, une des duplications publiques existantes est choisie comme nouveau référentiel en amont et tous les autres référentiels sont dupliqués à partir de ce nouveau référentiel en amont. Les demandes de tirage suivantes sont poussées vers ce nouveau référentiel en amont.

En d’autres termes, les duplications d’un référentiel public restent publiques dans leur propre réseau de référentiels distinct, même après que le référentiel en amont soit devenu privé. Cela permet aux propriétaires de duplication de continuer à travailler et à collaborer sans interruption. Si les duplications publiques n’ont pas été déplacées dans un réseau distinct de cette façon, les propriétaires de ces duplications doivent obtenir les autorisations d’accès appropriées pour tirer les changements du référentiel en amont (maintenant privé) et lui envoyer des demandes de tirage, même s’ils n’avaient pas besoin de ces autorisations avant.

Si un dépôt public a un accès en lecture Git anonyme activé et que le dépôt est rendu privé, toutes les duplications du dépôt perdent l'accès en lecture Git anonyme et ont à nouveau le paramètre désactivé par défaut. Si un dépôt dupliqué est rendu public, les administrateurs de dépôt peuvent réactiver l’accès en lecture Git anonyme. Pour plus d’informations, consultez « Activation de l’accès en lecture Git anonyme pour un dépôt ».

Suppression du dépôt privé

Si un dépôt public est rendu privé, puis supprimé, ses duplications publiques continuent d’exister dans un réseau distinct.

Changement d’un dépôt privé en dépôt public

Lorsqu’un dépôt privé est rendu public, tous les commits de ce référentiel, y compris les commits précédemment envoyés à des duplications privées de ce référentiel, sont migrés vers un nouveau réseau de dépôt public et deviennent visibles pour tous. Toutes les duplications privées créées précédemment restent privées, mais seront déconnectées du référentiel d’origine rendu public. Chaque duplication privée va devenir un dépôt privé distinct et crée son propre réseau indépendant de référentiels. Les nouvelles modifications apportées à ces réseaux ne seront pas accessibles à partir du référentiel d’origine qui a été rendu public.

Suppression du dépôt public

Si un dépôt privé est rendu public, puis supprimé, ses duplications privées continuent d’exister comme des dépôts privés autonomes dans des réseaux distincts.

Changement de la visibilité d’un dépôt interne

Si la stratégie de votre entreprise autorise la duplication, toute duplication d’un dépôt interne est privée. Si vous changez la visibilité d’un dépôt interne, toute duplication appartenant à une organisation ou un compte personnel reste privée.

Suppression du dépôt interne

Si vous changez la visibilité d’un dépôt interne, puis supprimez le dépôt, les duplications continuent d’exister dans un réseau distinct.

Pour aller plus loin