O que a transferência realmente muda
Uma transferência de repositório do GitHub move o repositório para uma conta proprietária diferente. Não é a mesma operação que renomear o nome de usuário do seu perfil. Alterar um nome de usuário muda a identidade pública da conta e as URLs construídas a partir dele; transferir um repositório muda quem é o dono daquele projeto específico. Se o seu objetivo é um nome de perfil mais limpo em vez de entregar um projeto a outra pessoa, as etapas de transferência abaixo são a ferramenta errada.
A distinção importa para o planejamento. Depois que a conta proprietária original for aposentada, ninguém poderá fazer login para aceitar convites, aprovar acompanhamentos ou corrigir um link esquecido. Tudo o que depende da conta antiga precisa ser resolvido antes desse ponto, não depois.
Pré-requisitos a confirmar antes de começar
Duas condições decidem se uma transferência pode prosseguir:
Uma transferência de repositório exige acesso de administrador e uma conta de destino compatível, sem nome de repositório ou rede de forks conflitante. Fonte
Na prática, isso significa verificar três coisas do lado do proprietário e uma do lado do destinatário antes de solicitar qualquer coisa:
| Verificação | Quem confirma | Por que bloqueia a transferência |
|---|---|---|
| A conta proprietária tem acesso de administrador ao repositório | Proprietário | Sem direitos de administrador, a transferência não pode ser iniciada |
| A conta de destino é compatível | Destinatário | Uma conta de destino incompatível impede a transferência |
| Não existe repositório com o mesmo nome na conta do destinatário | Destinatário | Um nome conflitante bloqueia a movimentação |
| Não há rede de forks conflitante | Destinatário | Uma rede de forks conflitante bloqueia a movimentação |
Se qualquer linha falhar, resolva antes de enviar a solicitação. Renomear o repositório do lado do destinatário ou escolher uma conta de destino diferente são decisões do destinatário, então combine-as com antecedência em vez de descobrir o conflito no meio da transferência.
A etapa de aceitação tem uma janela curta
Para transferências entre contas pessoais, o destinatário não é uma parte passiva. Ele precisa agir:
Para uma transferência para outra conta pessoal, o destinatário aceita um convite por e-mail que expira após um dia. Fonte
Uma expiração de um dia é o principal risco operacional deste fluxo. Se o destinatário estiver em outro fuso horário, de folga ou simplesmente não estiver olhando o e-mail, o convite pode expirar e a transferência terá de ser reiniciada. Combine um horário de envio em que o destinatário esteja acessível e avise-o para esperar a mensagem, em vez de deixá-la sem leitura.
Uma lista de verificação simples de proprietário/destinatário:
- Proprietário: confirme o acesso de administrador, o repositório exato a ser movido e que a conta do destinatário não tem conflito de nome ou de rede de forks.
- Destinatário: confirme a conta de destino e verifique os mesmos conflitos do lado dele.
- Ambos: combinem uma janela de envio em que o destinatário possa responder dentro de um dia.
- Proprietário: envie a solicitação de transferência.
- Destinatário: aceite o convite por e-mail prontamente e dê retorno.
- Proprietário: confirme que o repositório agora aparece na conta do destinatário antes de fazer qualquer coisa com a conta antiga.
Não aposente a conta proprietária até a etapa 6 ser confirmada. A conta antiga é o único lugar de onde uma transferência falha ou expirada pode ser reenviada.
O que acontece com os links públicos depois
O comportamento dos links é onde as transferências surpreendem as pessoas, porque dois tipos de links se comportam de maneira diferente:
Os links do repositório redirecionam após a transferência, mas os sites do GitHub Pages associados não são redirecionados; reutilizar o local antigo do repositório remove o redirecionamento do repositório. Fonte
Isso dá uma divisão clara para uma auditoria de links pós-transferência:
| Tipo de link | Após a transferência | Ação necessária |
|---|---|---|
| Links do repositório apontando para o local antigo | Redirecionam para o novo proprietário | Normalmente nada; verifique uma amostra |
| Site do GitHub Pages criado a partir do repositório | Não é redirecionado | Atualize todos os links publicados para o site do Pages |
| Local antigo do repositório reutilizado por outra pessoa | O redirecionamento é removido | Evite liberar o local antigo; mantenha os links atualizados |
A terceira linha é a mais provável de ser esquecida. Se o caminho antigo do repositório for reutilizado depois, o redirecionamento que cobria discretamente seus links antigos desaparece. Trate o redirecionamento como uma conveniência durante a migração, não como uma garantia permanente, e atualize os links que você controla em vez de depender dele.
Lista de verificação de links públicos pós-transferência
Execute isto depois que o destinatário confirmar a propriedade e antes de aposentar a conta proprietária:
- Abra uma amostra de links do repositório na sua documentação, nos READMEs e em qualquer site que referencie o projeto, e confirme que eles resolvem para o novo proprietário.
- Identifique todos os sites do GitHub Pages associados ao repositório, já que eles não são redirecionados, e atualize os links publicados para eles.
- Decida o que acontece com o local antigo do repositório para que ele não seja reutilizado de uma forma que remova o redirecionamento.
- Verifique links de lugares que você não controla, como textos externos ou favoritos compartilhados, e anote quais você pode e quais não pode atualizar.
- Mantenha a conta proprietária ativa até que tudo acima esteja concluído.
Migração de propriedade versus mudança de nome de usuário
Transferir um repositório e mudar o nome de usuário do perfil são tarefas separadas, com riscos separados. Uma transferência trata de quem é o dono de um projeto; uma mudança de nome de usuário trata da identidade pública da própria conta. Se o que você realmente quer é limpar a aparência do seu perfil em vez de entregar um repositório, comece pelo guia de nome de usuário: mudar seu nome de usuário do GitHub sem deixar links de perfil quebrados.
Se você for fazer as duas coisas, sequencie-as deliberadamente: resolva primeiro a propriedade do repositório, confirme que o novo proprietário pode agir de forma independente e só então mude ou aposente a conta antiga. Fazer na ordem inversa deixa a transferência dependente de uma conta da qual você já abriu mão.
Onde uma busca de nome de usuário se encaixa, e onde não se encaixa
Antes de aposentar uma conta, as pessoas muitas vezes querem saber quais vestígios públicos do nome de usuário antigo permanecem em outros lugares. Uma consulta de nome de usuário pode revelar correspondências de perfis públicos em outras plataformas, o que é útil como uma lista de leads para links que você talvez precise atualizar. Não é um inventário de contas, e uma correspondência não é prova de que a mesma pessoa seja dona das duas contas. Trate os resultados como lugares a verificar manualmente, não como confirmação de que um link está ativo ou de que uma conta pertence a você.
O TraceSeek cobre mais de 3.000 plataformas e retorna uma primeira varredura gratuita em 20–30 segundos. Isso pode ajudar a montar uma lista de verificação de perfis públicos a revisar, mas não verifica propriedade e não substitui as verificações de transferência e de links acima. A transferência do repositório em si acontece no GitHub, não em uma ferramenta de busca.
Uma ordem realista de operações
- Decida se você precisa de uma transferência de repositório, de uma mudança de nome de usuário ou de ambas.
- Confirme o acesso de administrador, a compatibilidade do destinatário e a ausência de conflito de nome ou de rede de forks.
- Envie a transferência quando o destinatário puder aceitar dentro de um dia.
- Confirme que o repositório está sob o novo proprietário.
- Audite os links do repositório e, separadamente, quaisquer links do GitHub Pages.
- Proteja o local antigo do repositório contra reutilização.
- Só então aposente a conta proprietária.