Comment puis-je faire oublier ou dissocier GitHub que mon dépôt était à l'origine un fork d'un autre projet?
J'ai bifurqué un projet dans GitHub. Je peux maintenant voir "bifurquer de tout / peu importe". Le référentiel parent "que ce soit / quoi que ce soit" n'est plus maintenu. J'ai été autorisé à continuer d'utiliser la base de code du référentiel d'origine pour créer un référentiel indépendant.
Existe-t-il un moyen de détacher mon projet du référentiel d'origine?
Réponses:
Vous pouvez contacter le support github et leur demander de basculer votre référentiel en "mode normal".
Sur cette page , le paragraphe "Commit was made in a fork", il est expliqué qu'il faut passer par le support pour passer. Par conséquent, il est probable qu'il n'y ait aucun moyen de le faire par vous-même (sauf si vous détruisez et recréez votre dépôt qui est expliqué avant ... si vous le faites, faites attention si vous avez des billets ou un wiki attaché à votre projet comme ils le feront être supprimé!).
Vous pouvez dupliquer le référentiel forké dans un nouveau référentiel (sans la dépendance fork) de l'interface utilisateur de github, puis supprimer celui d'origine:
Assurez-vous que vous disposez de toutes les branches et balises importantes sur votre référentiel local, supprimez le référentiel github, recréez le référentiel par les moyens habituels (sans forking) et repoussez le référentiel local avec git push --all. Notez que si vous avez des branches locales que vous ne souhaitez pas publier, il peut être utile de créer un clone local propre temporaire pour l'opération.
Cependant, cela supprimera également le wiki et les problèmes. Comme le wiki est en fait son propre référentiel, il peut être géré de la même manière en le clonant puis en le recréant et en le poussant. L'adresse du dépôt est sur la page Git Access du wiki ( git@github.com:user/repo.wiki.git).
Cela laisse des problèmes. Ils peuvent être exportés via l' API , mais pour autant que je sache, vous ne pouvez créer des problèmes et des commentaires qu'avec votre personne, il est donc impossible de les importer parfaitement.
Donc, si vous avez besoin de problèmes pour être préservés, vous devriez passer par le support github comme le suggère Thomas Moulard.
J'ai eu le même problème et j'ai fini par utiliser cette page d'aide github pour le résoudre. Cela ne me dérangeait pas pour le wiki et le traqueur de problèmes comme pour mon blog en utilisant un thème gentiment développé par un autre utilisateur.
Pour détacher un dépôt fourchu et l'utiliser comme le vôtre après plusieurs validations sans perdre tout l'historique:
git clone --bare git@github.com:user/forked_repo.git
Créez un nouveau référentiel vide new-repositorysur le site Web de Github. Et poussez une version miroir:
cd user.github.com.git/
git push --mirror git@github.com:user/new-repository.git
On peut renommer sur github, le forked_repositoryavec un autre nom pour le garder comme sauvegarde et vérifier les mises à jour si nécessaire. Ou supprimez-le simplement.
Renommer le new-repositoryau nom d'origine fait l'affaire. En tant qu'effet secondaire, vos commits apparaissent désormais dans votre historique.
Cela ne s'applique qu'à GitHub Enterprise, pas sur github.com
Connecté à un compte disposant de privilèges d'administrateur:
https://<ghe url>/<org>/<repo>Cela a été testé sur GitHub Enterprise 2.9
En utilisant les informations d' Aurelien et de Clayton , j'ai pu le faire avec les éléments suivants:
$ git clone --bare https://github.com/my/forked_repo.git
<delete forked_repo on GitHub>
<recreate repo on GitHub using same name>
$ cd forked_repo.git
$ git push --mirror
Voici la documentation pourgit clone --bare :
Créez un référentiel Git nu. Autrement dit, au lieu de créer
<directory>et de placer les fichiers administratifs dans<directory>/.git, faites le<directory>lui-même$GIT_DIR. Cela implique évidemment le -n car il n'y a nulle part où vérifier l'arbre de travail. De plus, les têtes de branche de la télécommande sont copiées directement dans les têtes de branche locales correspondantes, sans les mapperrefs/remotes/origin/. Lorsque cette option est utilisée, ni les branches de suivi à distance ni les variables de configuration associées ne sont créées.
Voici la documentation pourgit push --mirror :
Au lieu de nommer chaque arbitre pour pousser, précise que tous les refs sous
refs/(qui comprend , mais sans s'y limiterrefs/heads/,refs/remotes/etrefs/tags/) être mis en miroir le dépôt distant. Les références locales nouvellement créées seront transmises à l'extrémité distante, les références mises à jour localement seront mises à jour de force sur l'extrémité distante et les références supprimées seront supprimées de l'extrémité distante. Il s'agit de la valeur par défaut si l'option de configurationremote.<remote>.mirrorest définie.
Remarque: comme les autres gitréponses basées, cela ne copiera pas les problèmes qui ne font pas partie du gitréférentiel tels que le wiki et les problèmes. Par Tapio:
git@github.com:user/repo.wiki.git .