No git, é uma má idéia criar uma tag com o mesmo nome de uma ramificação excluída?

Eu tenho um projeto com um modelo de ramificação git que segue aproximadamente o fluxo git de nvie .

Nossos ramos de lançamento são nomeados no formato SemVer , por exemplo,v1.5.2

Depois que uma ramificação de liberação recebe luz verde para produção, fechamos a ramificação, mesclando-a no mestre, aplicando uma tag e excluindo a ramificação.

Como excluímos imediatamente o ramo de lançamento, usamos o mesmo identificador para marcar o ramo, por exemplo, v1.5.2

Aqui estão os comandos que usamos para fechar um ramo de lançamento:

$ git checkout master
$ git merge v1.5.2
$ git tag -a v1.5.2 -m "Version 1.5.2 - foo bar, baz, etc"
$ git branch -d v1.5.2
$ git branch -dr origin/v1.5.2
$ git push origin :v1.5.2
$ git push
$ git push --tags

Isso parece funcionar na maioria dos casos, no entanto, está causando um problema no cenário em que outra instância do repositório git (por exemplo, outra máquina de desenvolvimento ou ambiente de teste) tem uma verificação local da ramificação v1.5.2.

O git push origin :v1.5.2comando excluirá a ramificação no controle remoto, mas não excluirá a versão local da ramificação (se existir) em todos os repositórios.

Isso leva a uma referência ambígua ao tentar fazer checkout v1.5.2nesses repositórios:

$ git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.

Isso pode ser evitado sem o uso de uma sintaxe diferente para os ramos, por exemplo release-v1.5.2, ou v1.5.2-rc?

Ou é inevitável e, portanto, é uma péssima idéia criar uma tag com o mesmo nome de uma ramificação excluída?

Se você deseja absolutamente manter esse esquema de nomenclatura, você pode:

Decida que você não se importa com esses avisos

Ou seja, se você está feliz com o fato de que:

• git checkout <ref>fará o check-out refs/heads/<ref>mais refs/tags/<ref>(consulte git-checkout )
• outros comandos usarão refs/tags/<ref>over refs/heads/<ref>(veja gitrevisions )

Por exemplo, neste repositório de teste, a v1.5.2ramificação aponta para confirmar B, mas a v1.5.2tag aponta para confirmar A.

% git log --oneline --decorate
8060f6f (HEAD, v1.5.2, master) commit B
0e69483 (tag: v1.5.2) commit A

git checkout prefere nomes de ramificações:

% git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.
Switched to branch 'v1.5.2'
% git log --decorate --oneline -1
8060f6f (HEAD, v1.5.2, master) commit B

mas git logusará o nome da tag:

% git log --decorate --oneline -1 v1.5.2
warning: refname 'v1.5.2' is ambiguous.
0e69483 (tag: v1.5.2) commit A

Isso pode ser confuso.

Treine as pessoas para excluir suas ramificações locais quando virem uma nova tag

Isso pode ser difícil / complicado, dependendo do tamanho da sua organização.

Escreva um invólucro em torno de "git pull" e "git fetch"

Ou seja, escreva um wrapper que verifique se há alguma marca que oculte os nomes das ramificações e avise (ou exclua) essas ramificações. Isso parece doloroso e pode ser indesejável se o ramo sombreado estiver atualmente em check-out.

Infelizmente, parece que a maneira mais fácil de resolver esse problema pode ser alterar a maneira como você nomeia suas filiais. O link que você postou usa diferentes esquemas de nomeação para tags e ramificações: se você já está seguindo esse método, a adoção do esquema de nomeação pode ser a solução mais fácil.

Você pode especificar explicitamente se deseja uma ramificação ou uma tag usando o nome completo:

 git checkout refs/heads/v1.5.2

ou

git checkout refs/tags/v1.5.2