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

Question

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

#1 da (17 voti)
#2 da (5 voti)

16

Ho un progetto con un modello git branching che segue approssimativamente quello di nvie's git-flow .

I nostri rami di rilascio sono denominati in un formato SemVer , ad es. v1.5.2

Una volta che un ramo di rilascio riceve la luce verde per la produzione, chiudiamo il ramo, unendolo in master, applicando un tag e quindi eliminando il ramo.

Come eliminiamo immediatamente il ramo di rilascio, abbiamo utilizzato 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 staging) ha un checkout locale del ramo v1.5.2. / p>

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

Questo porta ad un riferimento ambiguo, quando provi il checkout di v1.5.2 in questi repository:

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

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

O è inevitabile e quindi un'idea fondamentalmente sbagliata per creare un tag con lo stesso nome di un ramo cancellato?

git version-control branching gitflow

posta tommarshall 26.02.2014 - 11:43

fonte

2 risposte

5

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

risposta data 10.09.2018 - 17:05

fonte

Leggi altre domande sui tag git version-control branching gitflow

Cos'è la programmazione basata su pattern? Le best practice per gestire la concorrenza in un paniere in un sito di e-commerce

score 17 · Accepted Answer

Se vuoi assolutamente mantenere questo schema di denominazione, potresti:

Decidi di non preoccuparti di questi avvisi

Cioè, se sei soddisfatto del fatto che:

git checkout <ref> controllerà refs/heads/<ref> su refs/tags/<ref> (vedi git-checkout )
altri comandi utilizzeranno refs/tags/<ref> su refs/heads/<ref> (vedi gitrevisions )

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

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

git checkout preferisce nomi di rami:

% 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 log utilizzerà 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.

Istruisci le persone a eliminare i loro rami locali quando vedono un nuovo tag

Potrebbe essere difficile / difficile a seconda delle dimensioni della tua organizzazione.

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

Cioè, scrivi un wrapper che controlli se ci sono tag che ombreggiano i nomi dei rami, e avvisa (o cancella) quei rami. Ciò sembra doloroso e potrebbe essere indesiderato se il ramo ombreggiato è attualmente estratto.

Sfortunatamente, sembra che il modo più semplice per risolvere questo problema potrebbe essere quello di cambiare il nome dei tuoi rami. Il link che hai pubblicato utilizza diversi schemi di denominazione per tag e rami: se stai già seguendo principalmente questo metodo, l'adozione del suo schema di denominazione potrebbe essere la soluzione più semplice.