En git, ¿es una mala idea crear una etiqueta con el mismo nombre que una rama eliminada?

Tengo un proyecto con un modelo de ramificación git que sigue aproximadamente el del flujo git de nvie .

Nuestras ramas de lanzamiento se nombran en un formato SemVer , por ejemplov1.5.2

Una vez que una rama de lanzamiento recibe luz verde para la producción, cerramos la rama, fusionándola en maestra, aplicando una etiqueta y luego eliminando la rama.

Como eliminamos inmediatamente la rama de lanzamiento, hemos estado utilizando el mismo identificador para etiquetar la rama, por ejemplo v1.5.2

Aquí están los comandos que usaríamos para cerrar una rama de lanzamiento:

$ 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

Esto parece funcionar en la mayoría de los casos, sin embargo, está causando un problema en el escenario en el que otra instancia del repositorio de git (por ejemplo, otra máquina de desarrollo o entorno de preparación) tiene una comprobación local de la rama v1.5.2.

El git push origin :v1.5.2comando eliminará la rama en el control remoto, pero no elimina la versión local de la rama (si existe) en todos los repositorios.

Esto lleva a una referencia ambigua, cuando intentas pagar v1.5.2en esos repositorios:

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

¿Se puede evitar esto sin usar una sintaxis diferente para las ramas, por ejemplo release-v1.5.2, o v1.5.2-rc?

¿O es inevitable y, por lo tanto, una idea fundamentalmente mala para crear una etiqueta con el mismo nombre que una rama eliminada?

Si desea mantener este esquema de nombres, puede:

Decide que no te importan estas advertencias

Es decir, si está contento con el hecho de que:

• git checkout <ref>saldrá refs/heads/<ref>más de refs/tags/<ref>(ver git-checkout )
• otros comandos usarán refs/tags/<ref>over refs/heads/<ref>(ver gitrevisions )

Por ejemplo, en este repositorio de prueba, la v1.5.2rama apunta a confirmar B, pero la v1.5.2etiqueta apunta a confirmar A.

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

git checkout prefiere nombres de sucursal:

% 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

pero git logusará el nombre de la etiqueta:

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

Esto puede ser confuso.

Capacite a las personas para eliminar sus sucursales locales cuando vean una nueva etiqueta

Esto puede ser difícil / incómodo dependiendo del tamaño de su organización.

Escribe un contenedor alrededor de "git pull" y "git fetch"

Es decir, escriba un contenedor que verifique si hay alguna etiqueta que sombree los nombres de las ramas y advierta (o elimine) esas ramas. Esto suena doloroso y podría ser indeseable si la rama sombreada está actualmente desprotegida.

Desafortunadamente, parece que la forma más fácil de resolver este problema podría ser cambiar la forma en que nombra sus ramas. El enlace que publicó utiliza diferentes esquemas de nombres para etiquetas y ramas: si ya está siguiendo principalmente ese método, adoptar su esquema de nombres podría ser la solución más fácil.

Puede especificar explícitamente si desea una rama o una etiqueta utilizando el nombre completo:

 git checkout refs/heads/v1.5.2

o

git checkout refs/tags/v1.5.2