Forker un dépôt sur GitHub mais autoriser de nouveaux problèmes sur le fork
J'ai déjà bifurqué les dépôts d'autres personnes sur GitHub, et j'ai remarqué que les problèmes restent avec le dépôt d'origine et que je ne peux pas déposer de problèmes sur le dépôt fourchu.
J'ai maintenant la tâche suivante. Je travaille pour une petite entreprise où le développement était effectué par l'un des directeurs sur son compte personnel. Il a quitté le projet à l'amiable, et nous aimerions migrer ce projet de son compte personnel vers un nouveau compte "rôle" sur GitHub.
Je bifurquerais naturellement le dépôt, afin de préserver l'historique du code, mais je me retrouverais ensuite avec un dépôt où nous ne pourrions pas déposer de nouveaux problèmes, ce qui est assez indésirable.
Comment puis-je faire une copie de ce dépôt d'origine dans notre nouveau compte, idéalement tout en conservant l'historique du code, mais être en mesure de déposer de nouveaux problèmes dans ce nouveau compte?
Après un test rapide, il est possible d'attacher un problème à votre propre fork d'un dépôt. Voici ce que j'ai fait :
- Fork un repo
- Accédez à la page Paramètres de votre fork.
- Cochez la case à côté de
Issues
Vous pouvez maintenant déposer des problèmes sur votre propre fork et ils ne seront pas placés dans le référentiel principal.
Il y a également la possibilité de transférer (propriété) d'un référentiel d'un compte à un autre (par exemple d'un ancien employé vers un compte `` organisation '').
- Le bouton "Transférer la propriété" se trouve en bas de la page Paramètres du référentiel, dans la section "Zone de danger".
- Le propriétaire actuel du référentiel doit disposer de privilèges administratifs sur l'organisation de destination (bien que cela puisse être temporaire).
C'est une question ancienne, et je serais favorable à l'approche que David P présente.
Une autre option consiste à se rappeler qu'un référentiel Git local est un référentiel complet, complet avec l'historique du code. Vous pourriez Poussez-le simplement comme un autre référentiel sur GitHub, de telle sorte que GitHub n'aurait aucune idée que les 2 étaient liés. Vous voyez toujours l'intégralité de votre historique de validation.
Cette approche vous ferait perdre tout historique de suivi des problèmes que vous avez. L'approche de David P est supérieure à la mienne, l'OMI.