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

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.

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.

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.

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.

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.

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:

  • el objeto al que apunta
  • El tipo de objeto al que apunta. Sí, los objetos de etiqueta pueden apuntar a cualquier otro tipo de objeto como blobs, no solo commits .
  • el nombre de la etiqueta
  • identidad del etiquetador y marca de tiempo
  • mensaje. Observe cómo la firma PGP se agrega al mensaje

  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

• Determine si una etiqueta está anotada:

  git cat-file -t tag
  

  Salidas commitpara peso ligero, tagpara anotado.

• Enumerar solo etiquetas livianas: ¿Cómo puedo enumerar todas las etiquetas livianas?

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

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.

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.

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.