In git, è una cattiva idea creare un tag con lo stesso nome di un ramo eliminato?

Ho un progetto con un modello di ramificazione git che segue approssimativamente quello del flusso git di nvie .

Le nostre filiali di rilascio sono denominate in un formato SemVer , ad esv1.5.2

Una volta che un ramo di rilascio ha ricevuto il via libera per la produzione, chiudiamo il ramo, fondendolo in master, applicando un tag e quindi eliminando il ramo.

Poiché eliminiamo immediatamente il ramo di rilascio, abbiamo usato lo stesso identificatore per contrassegnare il ramo, ad es v1.5.2

Ecco i comandi che useremmo per chiudere un ramo di rilascio:

$ 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

Questo sembra funzionare nella maggior parte dei casi, tuttavia sta causando un problema nello scenario in cui un'altra istanza del repository git (ad esempio un'altra macchina di sviluppo o ambiente di gestione temporanea) ha un checkout locale del ramo v1.5.2.

Il git push origin :v1.5.2comando eliminerà il ramo nel telecomando, ma non elimina la versione locale del ramo (se esiste) in tutti i repository.

Ciò porta a un riferimento ambiguo, quando si tenta di effettuare il checkout v1.5.2in questi repository:

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

Questo può essere evitato senza usare una sintassi diversa per i rami, ad esempio release-v1.5.2, o v1.5.2-rc?

O è inevitabile, e quindi una pessima idea creare un tag con lo stesso nome di un ramo cancellato?

Se vuoi assolutamente mantenere questo schema di denominazione, potresti:

Decidi che non ti interessano questi avvisi

Cioè, se sei soddisfatto del fatto che:

• git checkout <ref>verificherà out refs/heads/<ref>over refs/tags/<ref>(vedi git-checkout )
• altri comandi useranno refs/tags/<ref>oltre refs/heads/<ref>(vedi gitrevisions )

Ad esempio, in questo repository di test, il v1.5.2ramo punta a commettere B, ma il v1.5.2tag punta a commettere A.

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

git checkout preferisce i nomi delle filiali:

% 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

ma git logutilizzerà il nome del tag:

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

Questo potrebbe essere fonte di confusione.

Addestra le persone ad eliminare le loro filiali locali quando vedono un nuovo tag

Questo potrebbe essere difficile / imbarazzante a seconda delle dimensioni della tua organizzazione.

Scrivi un wrapper attorno a "git pull" e "git fetch"

Ossia, scrivi un wrapper che controlla se ci sono tag che ombreggiano i nomi dei rami e avvisa (o elimina) di quei rami. Questo suona doloroso e potrebbe essere indesiderabile se il ramo in ombra è attualmente estratto.

Sfortunatamente, sembra che il modo più semplice per risolvere questo problema sia cambiare il modo in cui dai un nome ai tuoi rami. Il link che hai pubblicato utilizza diversi schemi di denominazione per tag e rami: se stai già seguendo per lo più quel metodo, adottare il suo schema di denominazione potrebbe essere la soluzione più semplice.

Puoi specificare esplicitamente se vuoi un ramo o un tag usando il nome completo:

 git checkout refs/heads/v1.5.2

o

git checkout refs/tags/v1.5.2