Como corrigir “would clobber existing tag” no Git.
O Git informa “would clobber existing tag” quando um fetch substituiria uma tag local existente por outro objeto. Compare as duas referências da tag, preserve a referência local e atualize somente essa tag se a versão remota for a correta.
A resposta segura
Encontre a tag indicada no erro. Compare os IDs dos objetos local e remoto, crie um backup local e force o fetch somente dessa tag verificada se a versão remota estiver correta. Não force todas as tags nem envie uma substituição ao remoto.
Tags anotadas têm seus próprios IDs de objeto. Dois objetos de tag podem apontar para o mesmo commit e diferir na mensagem ou assinatura; compare as referências das tags e seus alvos desreferenciados antes de decidir o que mudou.
1. Inspecione a tag exata
Substitua v1.2.3 pela tag indicada no erro e origin pelo seu remoto. Estes comandos não alteram referências.
git show-ref --verify refs/tags/v1.2.3
git rev-parse 'refs/tags/v1.2.3^{}'
git ls-remote --tags origin 'refs/tags/v1.2.3' 'refs/tags/v1.2.3^{}'O primeiro comando mostra o ID do objeto da tag local. O segundo atravessa uma tag anotada até o objeto de destino. A saída remota mostra a referência da tag e, para uma tag anotada, uma linha terminada em ^{} com seu alvo desreferenciado.
Use os nomes completos das referências mostrados aqui: uma busca pelo prefixo v1.2.3 também poderia incluir v1.2.30. Se o remoto não tiver uma tag correspondente, pare; este procedimento não é motivo para excluir a tag local.
2. Preserve a referência local original
Crie uma tag local de recuperação antes de substituir qualquer coisa. O argumento final vazio exige que o nome do backup ainda não esteja em uso.
git update-ref refs/tags/backup/v1.2.3 refs/tags/v1.2.3 ""
git rev-parse refs/tags/v1.2.3 refs/tags/backup/v1.2.3Os dois IDs de objeto precisam ser iguais. Isso preserva o objeto da tag original, inclusive a mensagem e a assinatura de uma tag anotada. Se a criação falhar porque o backup já existe, escolha outro nome e verifique-o antes de continuar.
Mantenha o backup até resolver a divergência. Ele permanece local a menos que você o envie; não use git push --tags neste reparo.
3. Atualize somente a tag verificada
Execute isto apenas depois de confirmar que a tag remota é a correta e que o backup existe. O + inicial autoriza a substituição apenas desta referência local.
git fetch --no-tags --no-prune --no-prune-tags origin '+refs/tags/v1.2.3:refs/tags/v1.2.3'
git show-ref --verify refs/tags/v1.2.3
git rev-parse 'refs/tags/v1.2.3^{}'--no-tags desativa o acompanhamento automático de outras tags. --no-prune e --no-prune-tags desativam, neste fetch, a remoção normal e a remoção configurada de tags, para que o reparo não seja ampliado. Nenhuma branch ou tag remota é enviada ou substituída.
Compare o objeto da tag buscada e seu alvo desreferenciado com os IDs remotos que você inspecionou. Se o remoto mudar durante o reparo, pare e investigue antes de usar a tag em uma versão. O backup ainda aponta para seu objeto original.
Por que o Git rejeita a atualização
Desde o Git 2.20, fetch exige um force explícito para substituir uma referência refs/tags/* existente. Essa regra vale mesmo quando os dois alvos têm relação no histórico de commits; tags não são atualizadas pelas regras de fast-forward das branches.
Se sua tag local for a correta para a versão, mantenha-a e alinhe a decisão com quem mantém o projeto. Substituir uma tag remota já publicada muda o que outros usuários recebem com o mesmo nome de versão.
Referências oficiais do Git
Inspecione primeiro e depois altere a menor referência possível.
O FluxGit reúne tags, organização do repositório e operações protegidas em um cliente Git para desktop no macOS, Windows e Linux. Use os comandos acima para diagnosticar este erro do Git antes de alterar uma referência.