Como posso fazer o GitHub esquecer ou desassociar que meu repositório era originalmente uma bifurcação de outro projeto?
Eu criei um projeto no GitHub. Agora posso ver "bifurcada de qualquer coisa / qualquer coisa". O repositório pai "Whatever / Whatever" não é mais mantido. Foi-me permitido continuar usando a base de código do repositório original para criar um repositório independente.
Existe uma maneira de desanexar meu projeto do repositório original?
Respostas:
Você pode entrar em contato com o suporte do github e pedir que eles mudem seu repositório para o "modo normal".
Por esta página , "Entrega foi feita em um garfo" parágrafo, é explicado que um tem que ir através do apoio ao switch. Portanto, é provável que não há nenhuma maneira de fazer isso por si mesmo (a menos que você destruir e recriar a sua repo que é explicado antes ... se você por isso tome cuidado se você tiver bilhetes ou um wiki anexado ao seu projeto como eles vão ser excluído!).
Você pode duplicar o repositório bifurcado em um novo repositório (sem a dependência da bifurcação) da interface do usuário do github e remover o original bifurcado:
Certifique-se de ter todas as ramificações e tags importantes em seu repositório local, exclua o repositório github, recrie o repositório pelos meios usuais (sem bifurcação) e empurre o repositório local novamente git push --all. Observe que, se você tiver ramificações locais que não deseja publicar, pode valer a pena criar um clone local limpo temporário para a operação.
No entanto, isso também irá livrar-se do wiki e dos problemas. Como o wiki é de fato seu próprio repositório, ele pode ser tratado da mesma forma clonando-o e, em seguida, recriando e pressionando. O endereço de repo está na página de acesso Git do wiki ( git@github.com:user/repo.wiki.git).
Isso deixa problemas. Eles podem ser exportados por meio da API , mas, tanto quanto eu sei, você só pode criar problemas e comentários com sua pessoa, portanto, é impossível importá-los perfeitamente.
Portanto, se você precisar que os problemas sejam preservados, você deve passar pelo suporte do github, como sugere Thomas Moulard.
Eu tive o problema semelhante e acabei usando esta página de ajuda do github para resolvê-lo. Eu não me importei com o rastreador de wiki e problemas, como era para o meu blog usando um tema desenvolvido por outro usuário.
Para desanexar um repositório bifurcado e usá-lo como seu após várias confirmações sem perder toda a história:
git clone --bare git@github.com:user/forked_repo.git
Crie uma nova repositório vazio new-repositoryno site do github. E empurre uma versão espelhada:
cd user.github.com.git/
git push --mirror git@github.com:user/new-repository.git
É possível renomear no github, forked_repositorycom outro nome para mantê-lo como backup e verificar as atualizações, se necessário. Ou simplesmente exclua-o.
Renomear new-repositorypara o nome original faz o trabalho. Como efeito colateral, seus commits agora aparecem no seu histórico.
Isso se aplica apenas ao GitHub Enterprise, não no github.com
Conectado a uma conta que tenha privilégios de administrador:
https://<ghe url>/<org>/<repo>Isso foi testado no GitHub Enterprise 2.9
Usando as informações de aurelien e Clayton , consegui fazer o seguinte:
$ 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
Aqui está a documentação paragit clone --bare :
Faça um repositório simples do Git. Ou seja, em vez de criar
<directory>e colocar os arquivos administrativos<directory>/.git, faça o<directory>próprio$GIT_DIR. Obviamente, isso implica o -n porque não há lugar para verificar a árvore de trabalho. Além disso, as cabeças de ramificação no controle remoto são copiadas diretamente para as cabeças de ramificação locais correspondentes, sem as mapearrefs/remotes/origin/. Quando essa opção é usada, nem ramificações de rastreamento remoto nem as variáveis de configuração relacionadas são criadas.
Aqui está a documentação paragit push --mirror :
Em vez de nomear cada árbitro para empurrar, especifica que todos os refs sob
refs/(o que inclui, mas não está limitado arefs/heads/,refs/remotes/, erefs/tags/) ser espelhado para o repositório remoto. As refs locais recém-criadas serão enviadas para a extremidade remota, as refs atualizadas localmente serão atualizadas à força na extremidade remota e as refs excluídas serão removidas da extremidade remota. Esse é o padrão se a opção de configuraçãoremote.<remote>.mirrorestiver definida.
Nota: como as outras gitrespostas baseadas, isso não será copiado sobre problemas que não fazem parte do gitrepositório, como o wiki e os problemas. Por Tapio:
git@github.com:user/repo.wiki.git.