¿Las tags de git se aplican a todas las twigs?

Me estoy mojando los pies con el labeldo de git, pero mi experiencia previa está en Subversion, donde las "tags" eran realmente solo copys, no tags "reales" …

Si agrego una label a un repository git, ¿se aplica a todas las twigs o solo a la actual?

Por ejemplo, si actualmente tengo estas twigs ( git branch -v ):

 * master deadbeef My master head comment dev baddfeed My def head comment 

Y la twig actualmente desprotegida es maestra, como puede ver. Ahora supongamos que git tag -a TAGNAME , ¿aplica TAGNAME solo a deadbeef (twig principal) o a baddfeed (twig dev) también?

por ejemplo, decir que posteriormente cambio a la twig de desarrollo (es decir, no a la twig en la que se creó la label) antes de retirar la label:

 git checkout dev git checkout TAGNAME 

¿Luego termino con un checkout de baddfeed o el checkout de la label (segunda línea) me cambiará a la twig principal (donde se creó la label) y me dará un checkout de deadbeef ? (O tercera opción, ¿mi comprensión de crear y restaurar tags es demasiado errónea o demasiado simplist para que la respuesta sea tan simple como una de esas dos opciones?)

Además, ¿la respuesta a mi pregunta cambia si uso una label liviana ( git tag TAGNAME ) en lugar de una label anotada?

Digamos que estás en la twig myBranch . Y creas una label llamada myTag

 -----A-----B-----C-----D-----H-------I-----> master \ \ \---E----F-----G-----> myBranch | myTag 

La label solo estará en el object de confirmación de la twig myBranch . También trabajé con CVS, y también marca las revisiones, no todas las twigs (pero en las twigs de CVS son tags especiales). No lo creo

Si myTag , estarás en el commit G del ejemplo. No puede crear tags con el mismo nombre en diferentes twigs. Si lo haces, moverás la label.

No hay diferencia para una label anotada relacionada con esto.

Nota: cuando revisa las tags, termina con el modo "HEAD desconectado". Sus cambios se perderán a less que cree otra twig a partir de la label desprotegida.

Después de leer las preguntas y sus comentarios, creo que el punto básico que lo confunde aquí es lo que significa que en git (frente a otros sistemas) estar "en una twig".

En git, una operación de git checkout verifica una determinada confirmación [pero vea la nota al pie de página 1]. También establece el nombre especial HEAD para que se refiera a ese compromiso particular. Pero: hay dos maneras diferentes en que HEAD puede especificar un compromiso particular. Puede ser:

  • por ID (este es el caso no inusual), o
  • por reference indirecta a un nombre de twig (este es el caso más habitual).

Si haces git checkout branchname , git configura el segundo caso habitual. Si luego cat .git/refs/HEAD encontrará que contiene la cadena literal ref: seguida de refs/heads/ branchname [2]. Eso es lo que significa estar "en la twig": ha comprobado el compromiso al que se refiere el nombre de la sucursal, pero también, HEAD es una "reference simbólica". Si realiza nuevos cambios y los confirma, git realizará la nueva confirmación, luego "pelará" la nota adhesiva de la twig y la pegará en la nueva confirmación que acaba de agregar. Eso "mueve la twig" al consejo recién agregado, y "todavía estás en la twig".

Por otro lado, si haces git checkout tagname , git configura el primer caso inusual. Hace lo mismo si echa un vistazo por SHA-1 ID (esas ea56709... estilo ea56709... ). En este caso, el file para HEAD solo tiene la ID SHA-1 literal. En este estado, si realiza una nueva confirmación, se agrega como de costumbre, pero no hay cambios en las notas adhesivas para mover las tags de las twigs. No estás "en una twig"; HEAD no es una "reference simbólica".

En cuanto a las tags mismas, son simplemente nombres para confirmaciones. Pero espera, ¿no es eso lo que es una twig? ¡Sí! La diferencia entre un nombre de twig y un nombre de label es que se espera que un nombre de twig se mueva, y git lo moverá automáticamente en ese caso "en una twig". No se espera que un nombre de label se mueva [3] y nunca se moverá automáticamente.


Notas al pie:

[1] Solo para confundir las cosas (o porque la interfaz de usuario de git es "mala", como dirían algunos :-)) hay casos en que la git checkout no altera HEAD , específicamente cuando le pides que revise nombres de routes particulares.

[2] En versiones muy antiguas de git, en lugar de ref: ... git usaba un enlace simbólico. El objective del enlace era el file ID de la sucursal, por ejemplo, refs/heads/master o lo que sea, por lo que al abrir y leer el file se obtuvo el ID de confirmación, y se debe usar lstat para detectar "en una twig". Esto no funciona en Windows y excluye refs de "empaquetado" ( .git/packed-refs ), de ahí el cambio para usar ref: lugar.

[3] Las frases "se espera" y "no se espera" deberían incitarlo a preguntar: ¿ quién esperaba? Git en sí está bien con los usuarios de git que mueven tags, es la gente que usa git (y a menudo, los scripts que escriben) que se confunden con esto. Por lo tanto, no mueva una label a less que primero haya consultado con otras personas que comparten el repository.

Para hacerlo simple:

Si agrego una label a un repository git, ¿se aplica a todas las twigs o solo a la actual?

En Git, una label es simplemente un alias para una identificación de confirmación. Cuando agrega una label, Git simplemente asigna su nombre de label (la cadena de tags) a una identificación de confirmación determinada. Dado que la identificación de confirmación es relevante para una twig específica (o sucursales cuando se fusiona), la label será relevante solo para esa twig (y para cualquier entidad en la que se haya fusionado).

Aquí se puede encontrar más información:

http://git-scm.com/book/es/Git-Basics-Tagging#Creating-Tags