tipos tag remove qué existen etiquetas crear git git-tag

tag - tipos de etiquetas en git



¿Por qué debería preocuparme por las etiquetas ligeras frente a las anotadas? (8)

De forma predeterminada, Git solo ve las etiquetas anotadas como una línea de base para comandos como git describe . Piense en las etiquetas anotadas como señales 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 yo. Por lo tanto, vale la pena usar 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 recogido es el mismo código que Linus Torvalds lanzó en realidad. La firma también puede ser una afirmación de que el firmante está garantizando la calidad e integridad del software en ese compromiso.

Cambié de Subversion a Git como mi VCS diario 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 el de "peso ligero" frente a las anotadas frente a las etiquetas firmadas. Parece bastante universalmente aceptado que las etiquetas anotadas son superiores a las etiquetas ligeras 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é por primera vez a Git, las etiquetas livianas parecían ser lo mejor desde que se cortaba el pan; Simplemente podría señalar un compromiso y decir "eso fue 1.0". ¡Tengo problemas para comprender cómo una etiqueta podría necesitar algo más que eso, pero ciertamente no puedo creer que los expertos de Git del mundo prefieran las etiquetas anotadas arbitrariamente! Entonces, ¿qué es todo el bullicio?

(Puntos extra: ¿Por qué tendría que firmar una etiqueta?)

EDITAR

He estado 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 etiqueta? Tanto git tag -am "tagging 1.0" 1.0 como intentar resumir el registro de confirmación ya que la etiqueta anterior parece perder estrategias.

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

Firmar una etiqueta es una forma fácil de afirmar la autenticidad de una versión.

Esto es particularmente útil en un DVCS porque cualquier persona puede clonar el repositorio y modificar el historial (por ejemplo, a través de git-filter-branch). Si una etiqueta está firmada, la firma no sobrevivirá a una operación de git-filter-branch, por lo que si tiene una política de que cada lanzamiento está etiquetado y firmado por un interlocutor, 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.

He encontrado el único buen uso de las etiquetas ligeras: crear un lanzamiento en GitHub en forma retrospectiva.

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

Si solo creamos una etiqueta anotada en una confirmación antigua, GitHub tomaría la fecha para el lanzamiento del objeto de etiqueta. En contraste, cuando hemos creado una etiqueta ligera para este compromiso antiguo, la versión comenzó mostrando 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

La gran ventaja de una etiqueta anotada es que sabes quién la creó. Al igual que con los compromisos, a veces es bueno saber quién lo hizo. Si eres un 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í. publicado.

Los otros metadatos también pueden ser útiles, a veces es bueno saber cuándo se lanzó esa versión, no solo cuando 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 una versión candidata contiene un poco de una lista de tareas / tareas.

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

Editar:

En cuanto a qué escribir en una anotación de etiqueta, tiene razón, no siempre hay mucho que decir. 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 otros lugares, no hay necesidad de poner una allí. En este caso, lo que es más importante es el etiquetador y la fecha. Lo único en lo que puedo pensar es en algún tipo de sello de aprobación de un conjunto de pruebas. Eche un vistazo a las etiquetas de git.git: todos 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 obvios, el mensaje podría ser mucho más importante. Podría imaginar etiquetar una versión específica para propósitos especiales para un solo usuario / cliente, algún hito importante que no sea de la versión, o (como se mencionó anteriormente) un candidato de lanzamiento con información adicional. El mensaje es entonces mucho más útil.

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

git tag -a v1.0.0

Las etiquetas ligeras son la forma más sencilla de agregar una etiqueta a su repositorio git porque almacenan solo el hash de la confirmación a la que se refieren. Pueden actuar como "marcadores" para un compromiso, como tales, son ideales para uso privado.

git tag v1.0.0

Puede ordenar, listar, eliminar, mostrar y editar etiquetas antiguas. Todas estas funciones le 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.

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

  • Las etiquetas anotadas son aquellas que deben publicarse para otros desarrolladores, probablemente versiones nuevas (que también deberían estar firmadas). No solo para ver quién etiquetó y cuándo fue etiquetado, sino también por qué (generalmente un registro de cambios).
  • Los ligeros son más apropiados para uso privado, lo que significa etiquetar compromisos especiales para poder encontrarlos nuevamente. Puede ser revisarlos, revisarlos para probar algo o lo que sea.

Empuje las etiquetas anotadas, mantenga locales ligeros

Ciertos comportamientos de Git se 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 a la confirmación a la que apuntan. Así que podría usarlos para describir un lanzamiento sin hacer un compromiso de lanzamiento.

    Las etiquetas ligeras no tienen esa información adicional, y no la necesitan, ya que solo la usarás para desarrollarlas.

  • git push --follow-tags solo empujará 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 a ser liberadas, mientras que las etiquetas livianas están diseñadas para etiquetas de objetos privadas o temporales.

Diferencias internas

  • tanto las etiquetas ligeras como las anotadas son un archivo bajo .git/refs/tags que contiene un SHA-1

  • para etiquetas ligeras, el SHA-1 apunta directamente a un commit:

    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 ningún otro metadato.

  • 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 anotada:

    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 <[email protected]> 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 extra. 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 git tag y cómo calcular su SHA?

Bonificaciones