Ce que le transfert change réellement
Un transfert de dépôt GitHub déplace le dépôt vers un autre compte propriétaire. Ce n’est pas la même opération que renommer votre nom d’utilisateur de profil. Changer un nom d’utilisateur modifie l’identité publique du compte et les URL qui en découlent ; transférer un dépôt change qui possède ce projet précis. Si votre objectif est un nom de profil plus propre plutôt que de confier un projet à quelqu’un d’autre, les étapes de transfert ci-dessous ne sont pas le bon outil.
La distinction compte pour la planification. Une fois le compte propriétaire d’origine fermé, plus personne ne peut se connecter pour accepter des invitations, approuver des suites ou corriger un lien manqué. Tout ce qui dépend de l’ancien compte doit être réglé avant ce moment, pas après.
Prérequis à confirmer avant de commencer
Deux conditions décident si un transfert peut aboutir :
Un transfert de dépôt nécessite un accès administrateur et un compte destinataire compatible, sans nom de dépôt ni réseau de forks en conflit. Source
En pratique, cela signifie vérifier trois choses côté propriétaire et une côté destinataire avant de demander quoi que ce soit :
| Vérification | Qui la confirme | Pourquoi elle bloque le transfert |
|---|---|---|
| Le compte propriétaire dispose d’un accès administrateur au dépôt | Propriétaire | Sans droits d’administration, le transfert ne peut pas être lancé |
| Le compte destinataire est compatible | Destinataire | Un compte destinataire incompatible arrête le transfert |
| Aucun dépôt du même nom n’existe déjà chez le destinataire | Destinataire | Un nom en conflit bloque le déplacement |
| Aucun réseau de forks en conflit | Destinataire | Un réseau de forks en conflit bloque le déplacement |
Si une ligne échoue, résolvez-la avant d’envoyer la demande. Renommer le dépôt côté destinataire ou choisir un autre compte de destination sont des décisions du destinataire : convenez-en à l’avance plutôt que de découvrir le conflit en cours de transfert.
L’étape d’acceptation a une fenêtre courte
Pour les transferts entre comptes personnels, le destinataire n’est pas une partie passive. Il doit agir :
Pour un transfert vers un autre compte personnel, le destinataire accepte une invitation par e-mail qui expire au bout d’un jour. Source
Une expiration à un jour est le principal risque opérationnel de ce processus. Si le destinataire est dans un autre fuseau horaire, en congé, ou simplement ne surveille pas ses e-mails, l’invitation peut expirer et le transfert doit être relancé. Convenez d’une heure d’envoi où le destinataire est joignable, et prévenez-le pour qu’il attende le message plutôt que de le laisser sans lecture.
Une liste de vérification simple propriétaire/destinataire :
- Propriétaire : confirmer l’accès administrateur, le dépôt exact à déplacer, et que le compte du destinataire n’a ni conflit de nom ni conflit de réseau de forks.
- Destinataire : confirmer le compte de destination et vérifier les mêmes conflits de son côté.
- Les deux : convenir d’une fenêtre d’envoi où le destinataire peut répondre sous un jour.
- Propriétaire : envoyer la demande de transfert.
- Destinataire : accepter rapidement l’invitation par e-mail et faire un retour.
- Propriétaire : confirmer que le dépôt apparaît désormais sous le compte du destinataire avant toute action sur l’ancien compte.
Ne fermez pas le compte propriétaire tant que l’étape 6 n’est pas confirmée. L’ancien compte est le seul endroit d’où un transfert échoué ou expiré peut être renvoyé.
Ce qu’il advient des liens publics ensuite
Le comportement des liens est là où les transferts surprennent, car deux types de liens se comportent différemment :
Les liens du dépôt sont redirigés après le transfert, mais les sites GitHub Pages associés ne le sont pas ; réutiliser l’ancien emplacement du dépôt supprime la redirection du dépôt. Source
Cela donne une séparation claire pour un audit des liens après transfert :
| Type de lien | Après le transfert | Action nécessaire |
|---|---|---|
| Liens de dépôt pointant vers l’ancien emplacement | Redirigés vers le nouveau propriétaire | Généralement rien ; vérifier un échantillon |
| Site GitHub Pages construit à partir du dépôt | Non redirigé | Mettre à jour chaque lien publié vers le site Pages |
| Ancien emplacement du dépôt réutilisé par quelqu’un d’autre | La redirection est supprimée | Éviter de libérer l’ancien emplacement ; garder les liens à jour |
La troisième ligne est celle qui risque le plus d’être négligée. Si l’ancien chemin du dépôt est réutilisé plus tard, la redirection qui couvrait discrètement vos anciens liens disparaît. Considérez la redirection comme une commodité pendant la migration, pas comme une garantie permanente, et mettez à jour les liens que vous contrôlez plutôt que de compter dessus.
Liste de vérification des liens publics après transfert
À exécuter après que le destinataire a confirmé la propriété et avant que le compte propriétaire ne soit fermé :
- Ouvrez un échantillon de liens de dépôt depuis votre documentation, vos README et tout site qui référence le projet, et confirmez qu’ils mènent au nouveau propriétaire.
- Identifiez chaque site GitHub Pages associé au dépôt, puisqu’ils ne sont pas redirigés, et mettez à jour les liens publiés vers eux.
- Décidez ce qu’il advient de l’ancien emplacement du dépôt pour qu’il ne soit pas réutilisé d’une manière qui supprime la redirection.
- Vérifiez les liens provenant d’endroits que vous ne contrôlez pas, comme des articles externes ou des favoris partagés, et notez ceux que vous pouvez et ne pouvez pas mettre à jour.
- Gardez le compte propriétaire actif jusqu’à ce que tout ce qui précède soit fait.
Migration de propriété ou changement de nom d’utilisateur
Transférer un dépôt et changer un nom d’utilisateur de profil sont deux tâches distinctes avec des risques distincts. Un transfert concerne qui possède un projet ; un changement de nom d’utilisateur concerne l’identité publique du compte lui-même. Si ce que vous voulez réellement est de nettoyer l’apparence de votre profil plutôt que de céder un dépôt, commencez plutôt par le guide du nom d’utilisateur : changer votre nom d’utilisateur GitHub sans laisser de liens de profil cassés.
Si vous faites les deux, séquencez-les délibérément : réglez d’abord la propriété du dépôt, confirmez que le nouveau propriétaire peut agir de façon indépendante, et seulement ensuite changez ou fermez l’ancien compte. Faire l’inverse laisse le transfert dépendant d’un compte auquel vous avez déjà renoncé.
Où une recherche de nom d’utilisateur intervient, et où elle n’intervient pas
Avant de fermer un compte, on veut souvent savoir quelles traces publiques de l’ancien nom d’utilisateur subsistent ailleurs. Une recherche de nom d’utilisateur peut faire apparaître des correspondances de profil public sur d’autres plateformes, ce qui est utile comme liste de pistes pour les liens que vous devrez peut-être mettre à jour. Ce n’est pas un inventaire de comptes, et une correspondance ne prouve pas que la même personne possède les deux comptes. Traitez les résultats comme des endroits à vérifier à la main, pas comme la confirmation qu’un lien est actif ou qu’un compte vous appartient.
TraceSeek couvre plus de 3 000 plateformes et renvoie un premier scan gratuit en 20–30 secondes. Cela peut vous aider à construire une liste de profils publics à examiner, mais ne vérifie pas la propriété et ne remplace pas les vérifications de transfert et de liens ci-dessus. Le transfert de dépôt lui-même se fait sur GitHub, pas dans un outil de recherche.
Un ordre d’opérations réaliste
- Décidez si vous avez besoin d’un transfert de dépôt, d’un changement de nom d’utilisateur, ou des deux.
- Confirmez l’accès administrateur, la compatibilité du destinataire, et l’absence de conflit de nom ou de réseau de forks.
- Envoyez le transfert quand le destinataire peut accepter sous un jour.
- Confirmez que le dépôt se trouve sous le nouveau propriétaire.
- Auditez les liens du dépôt et, séparément, tout lien GitHub Pages.
- Protégez l’ancien emplacement du dépôt contre la réutilisation.
- Seulement ensuite, fermez le compte propriétaire.