¿Por qué debería importarme las etiquetas livianas o anotadas?


346

Cambié de Subversion a Git como mi VCS cotidiano el año pasado y todavía estoy tratando de comprender los puntos más finos de "Git-think".

El que me ha estado molestando últimamente es "ligero" versus etiquetas anotadas versus firmadas. Parece bastante universalmente aceptado que las etiquetas anotadas son superiores a las etiquetas livianas para todos los usos reales, pero las explicaciones que he encontrado de por qué ese es el caso siempre parecen reducirse a "porque las mejores prácticas" o "porque son diferentes". . Desafortunadamente, esos son argumentos muy insatisfactorios sin saber por qué son las mejores prácticas o cómo esas diferencias son relevantes para mi uso de Git.

Cuando cambié a Git por primera vez, las etiquetas livianas parecían ser lo mejor desde el pan rebanado; Podría señalar un commit y decir "eso fue 1.0". Tengo problemas para comprender cómo una etiqueta podría ser más que eso, ¡pero ciertamente no puedo creer que los expertos de Git del mundo prefieran etiquetas anotadas arbitrariamente! Entonces, ¿de qué se trata todo el bullicio?

(Puntos de bonificación: ¿Por qué necesitaría firmar una etiqueta?)

EDITAR

Me he convencido con éxito de que las etiquetas anotadas son algo bueno: ¡saber quién etiquetó y cuándo es importante! Como seguimiento, ¿algún consejo sobre buenas anotaciones de etiquetas? Ambos git tag -am "tagging 1.0" 1.0e intentando resumir el registro de confirmación ya que la etiqueta anterior parece perder estrategias.


¿Encontró una buena respuesta para su seguimiento? ¿Algo como? git log --pretty=oneline master..HEAD | git tag -a -F - $BRANCH.$BUILD_NUMBER
Dalore

Resumir el registro de confirmación desde la etiqueta anterior me parece una excelente estrategia para mensajes de etiqueta.
rooby

FYI (1.) Para listar la etiqueta LIGHTWEIGHT por fecha, vaya aquí . (2.) Para listar la etiqueta ANOTADA por fecha, vaya aquí .
Trevor Boyd Smith

Respuestas:


272

La gran ventaja de una etiqueta anotada es que sabes quién la creó. Al igual que con los commits, a veces es bueno saber quién lo hizo. Si eres desarrollador y ves que v1.7.4 ha sido etiquetado (declarado listo) y no estás tan seguro, ¿con quién hablas? ¡La persona cuyo nombre está en la etiqueta anotada! (Si vives en un mundo desconfiado, esto también evita que las personas se salgan con la suya al etiquetar cosas que no deberían). Si eres un consumidor, ese nombre es un sello de autoridad: es Junio ​​Hamano diciendo que esta versión de git está aquí. liberado.

Los otros metadatos también pueden ser útiles: a veces es bueno saber cuándo se lanzó esa versión, no solo cuándo se realizó la confirmación final. Y a veces el mensaje puede incluso ser útil. Tal vez ayude a explicar el propósito de esa etiqueta en particular. Tal vez la etiqueta para un candidato de lanzamiento contiene un poco de una lista de tareas / estado.

Firmar etiquetas es muy parecido a firmar cualquier otra cosa: proporciona un nivel más de seguridad para los paranoicos. La mayoría de nosotros nunca lo vamos a usar, pero si realmente quieres verificar todo antes de poner ese software en tu computadora, es posible que lo desees.

Editar:

En cuanto a qué escribir en una anotación de etiqueta, tiene razón: no siempre es muy útil decirlo. Para una etiqueta de número de versión, se entiende implícitamente que marca esa versión, y si está satisfecho con sus registros de cambios en otro lugar, no hay necesidad de poner uno allí. En este caso, lo más importante es realmente el etiquetador y la fecha. Lo único que se me ocurre es una especie de sello de aprobación de un conjunto de pruebas. Eche un vistazo a las etiquetas de git.git: todas dicen algo como "Git 1.7.3 rc1"; todo lo que realmente nos importa es el nombre de Junio ​​Hamano en ellos.

Sin embargo, para etiquetas con nombres menos evidentes, el mensaje podría ser mucho más importante. Podría imaginar etiquetar una versión específica de propósito especial para un solo usuario / cliente, algún hito importante sin versión o (como se mencionó anteriormente) un candidato de lanzamiento con información adicional. El mensaje es mucho más útil.


44
solo para comparar con SVN, ya que el OP proviene de ese sistema: los metadatos de la etiqueta anotada son equivalentes al cambio de SVN real que hace que la etiqueta se ramifique, que en SVN tiene su propio autor y mensaje. Y, potencialmente, separe las restricciones sobre quién puede hacer una etiqueta, distinta de quién puede registrar los cambios, una distinción que es irrelevante si solo está usando el sistema para sus propias cosas.
araqnid

10
Ah-ha! Parece que mi comprensión aquí se vio obstaculizada por el hecho de que todos mis proyectos de Git hasta ahora han sido en solitario. Nunca he necesitado saber a quién culpar por algo (¡siempre soy yo!), Así que no me di cuenta de que las etiquetas livianas no siguen al etiquetador.
Ben Blank

55
git help logahora lo resume así: "Las etiquetas anotadas están destinadas a la liberación, mientras que las etiquetas livianas están destinadas a las etiquetas de objetos privados o temporales".
Jon Gjengset

1
@javabrett Si bien esa es una buena parte de una respuesta a "¿cuáles son las diferencias entre las etiquetas anotadas y ligeras", la pregunta aquí era específicamente por qué las personas quieren almacenar información adicional y, por lo tanto, usar etiquetas anotadas. (Y no creo que pueda decir seriamente que "crea una gota" es un inconveniente: usted hace lo que debe hacer para almacenar la información que desea almacenar, y si es información importante, requerirá una gota. )
Cascabel

1
@Chris sí, como dice la respuesta, "La gran ventaja de una etiqueta anotada es que sabes quién la creó". Siempre puede probar las cosas usted mismo para descubrir:git tag -a -m 'my message' my-tag; git show my-tag
Cascabel

64

Mi opinión personal, ligeramente diferente sobre ese tema:

  • Las etiquetas anotadas son aquellas etiquetas destinadas a ser publicadas por otros desarrolladores, probablemente nuevas versiones (que también deben firmarse). No solo para ver quién etiquetó y cuándo se etiquetó, sino también por qué (generalmente un registro de cambios).
  • Los ligeros son más apropiados para uso privado, lo que significa etiquetar confirmaciones especiales para poder encontrarlos nuevamente. Puede ser para revisarlos, echarles un vistazo para probar algo o lo que sea.

44
Esto también se menciona en man git-tag: "Las etiquetas anotadas están destinadas a ser liberadas, mientras que las etiquetas livianas están destinadas a etiquetas de objetos privados o temporales": stackoverflow.com/a/35059291/895245
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

28

Por defecto, Git solo mira las etiquetas anotadas como una línea de base para comandos como git describe. Piense en las etiquetas anotadas como postes indicadores que tienen un significado duradero para usted y para los demás, mientras que las etiquetas livianas son más como marcadores para su posterior búsqueda. Por lo tanto, vale la pena usar las etiquetas anotadas como referencia, mientras que las etiquetas livianas no deberían serlo.

Firmar una etiqueta es una garantía de la identidad del firmante. Permite a los usuarios verificar, por ejemplo, que el código del kernel de Linux que han elegido es el mismo código que Linus Torvalds lanzó realmente. La firma también puede ser una afirmación de que el firmante garantiza la calidad e integridad del software en ese compromiso.


1
git push --follow-tagses otro comando que trata a ambos de manera diferente: stackoverflow.com/a/26438076/895245
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

1
Gracias por la pista sobre git describe. Lo uso en el sistema de integración continua y un par de veces la cadena de versión no era lo que esperaba.
jjmontes

9

Firmar una etiqueta es una manera fácil de afirmar la autenticidad de un lanzamiento.

Esto es particularmente útil en un DVCS porque cualquiera puede clonar el repositorio y modificar el historial (por ejemplo, a través de git-filter-branch). Si se firma una etiqueta, la firma no sobrevivirá a una operación git-filter-branch, por lo que si tiene una política de que cada lanzamiento está etiquetado y firmado por un confirmador, es posible detectar una etiqueta de lanzamiento falsa en el repositorio.

Si no fuera por la firma, tampoco vería mucho sentido en las etiquetas anotadas.


1
En realidad, para esto podría ser útil tener una firma que solo firme el árbol comprometido, no todo su historial (no me importa si alguien manipuló el historial, solo quiero estar seguro de que tengo el código correcto).
Paŭlo Ebermann

9

Empuje etiquetas anotadas, mantenga un peso ligero local

Ciertos comportamientos de Git diferencian entre ellos de manera que esta recomendación es útil, por ejemplo:

  • Las etiquetas anotadas pueden contener un mensaje, un creador y una fecha diferente de la confirmación a la que apuntan. Por lo tanto, puede usarlos para describir un lanzamiento sin realizar un compromiso de lanzamiento.

    Las etiquetas livianas no tienen esa información adicional y no la necesitan, ya que solo la usará usted mismo para desarrollarla.

  • git push: las siguientes etiquetas solo enviarán etiquetas anotadas
  • git describe sin opciones de línea de comando solo ve etiquetas anotadas

man git-tag dice:

Las etiquetas anotadas están destinadas al lanzamiento, mientras que las etiquetas livianas están destinadas a las etiquetas de objetos privados o temporales.

Diferencias internas

  • las etiquetas ligeras y anotadas son un archivo .git/refs/tagsque contiene un SHA-1

  • para etiquetas livianas, el SHA-1 apunta directamente a una confirmación:

    git tag light
    cat .git/refs/tags/light
    

    imprime lo mismo que el SHA-1 de HEAD.

    Así que no es de extrañar que no puedan contener otros metadatos.

  • Las etiquetas anotadas apuntan a un objeto de etiqueta en la base de datos de objetos.

    git tag -as -m msg annot
    cat .git/refs/tags/annot
    

    contiene el SHA del objeto de etiqueta anotado:

    c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
    

    y luego podemos obtener su contenido con:

    git cat-file -p c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
    

    salida de muestra:

    object 4284c41353e51a07e4ed4192ad2e9eaada9c059f
    type commit
    tag annot
    tagger Ciro Santilli <your@mail.com> 1411478848 +0200
    
    msg
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (GNU/Linux)
    
    <YOUR PGP SIGNATURE>
    -----END PGP SIGNAT
    

    Y así es como contiene metadatos adicionales. Como podemos ver en la salida, los campos de metadatos son:

    Un análisis más detallado del formato está presente en: ¿Cuál es el formato de un objeto de etiqueta git y cómo calcular su SHA?

Bonos


6

He encontrado el único uso bueno para las etiquetas livianas: crear una versión en GitHub en retrospectiva.

Lanzamos nuestro software y teníamos los commits necesarios, simplemente no nos molestamos en mantener la sección 'Release' en GitHub. Y cuando prestamos un poco de atención, nos dimos cuenta de que también querríamos agregar algunos lanzamientos anteriores, con las fechas de lanzamiento correctas para ellos.

Si solo creáramos una etiqueta anotada en una confirmación anterior, GitHub tomaría la fecha de lanzamiento del objeto de etiqueta. Por el contrario, cuando creamos una etiqueta liviana para este antiguo commit, el lanzamiento comenzó a mostrar la fecha correcta (antigua). Ayuda de Source @ GitHub, 'Acerca de los lanzamientos'

Parece que también es posible especificar la fecha deseada para una confirmación anotada, pero no me parece tan simple: https://www.kernel.org/pub/software/scm/git/docs/git-tag. html # _on_backdating_tags


Aunque hoy descubrí que GitHub dejó de honrar las fechas de etiqueta para mí (tanto para etiquetas ligeras como anotadas). Simplemente ignora la fecha cuando publica el lanzamiento y en su lugar recuerda la fecha y la hora en que presioné el botón "Publicar" para el lanzamiento.
evilkos

Sí, también me he topado con este desastre sobre GitHub y las etiquetas anotadas. No entendí por qué lo implementaron de esta manera ...
YakovL

1

En mi oficina pondremos la dirección de la página web de lanzamiento en el cuerpo de la etiqueta. La página web de lanzamiento detalla todas las nuevas características y correcciones desde la última versión. La gerencia no buscará en el repositorio de git para averiguar qué cambios ocurrieron, y es bueno tener una lista concisa de lo que hay en ese lanzamiento.


0

Las etiquetas anotadas almacenan metadatos adicionales, como el nombre del autor, las notas de la versión, el mensaje de la etiqueta y la fecha como objetos completos en la base de datos de Git. Todos estos datos son importantes para el lanzamiento público de su proyecto.

git tag -a v1.0.0

Las etiquetas livianas son la forma más simple de agregar una etiqueta a su repositorio git porque almacenan solo el hash del commit al que se refieren. Pueden actuar como "marcadores" para una confirmación, como tal, son excelentes para uso privado.

git tag v1.0.0

Puede ordenar, enumerar, eliminar, mostrar y editar etiquetas antiguas. Todas estas funciones lo ayudarán a identificar versiones de lanzamiento específicas de su código. encontré este artículo que podría ayudarlo a tener una mejor idea de lo que pueden hacer las etiquetas.


0

Para mí, la diferencia importante es que la etiqueta liviana no tiene marca de tiempo. Digamos que agregó varias etiquetas livianas:

git tag v1
git tag v2
git tag v3

y luego, tal vez más tarde, desea obtener la última etiqueta ligera agregada. No hay forma de hacerlo. Ni "git describe" ni "git tag" no le darán la última etiqueta liviana cronológicamente. "git tag -l" puede devolverlos todos o clasificarlos en orden lex, pero no por fecha / hora. "git describe --tags" devolverá "v1", que definitivamente no es la última etiqueta agregada.

Por otro lado, si agrega etiquetas anotadas:

git tag v1 -m v1
git tag v2 -m v1
git tag v3 -m v1

siempre puede obtener la marca de tiempo de cada etiqueta y "git describe" seguramente devolverá "v3", que es la última etiqueta agregada.


Tienes que usar -a para que se anote.
Alex
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.