He visto muchos proyectos usando v1.2.3 como la convención de nomenclatura para etiquetas en git. También he visto algunos usar 1.2.3. ¿Hay un estilo respaldado oficialmente o hay buenos argumentos para usar cualquiera?¿Existe una convención de nomenclatura estándar para etiquetas git?
Hay Semantic Versioning, por Tom Preston-Werner de github fama:
Tagging Especificación (SemVerTag)
Este sub-especificación debe utilizarse si se utiliza un sistema de control de versiones (Git, Mercurial, SVN, etc.) para almacenar su código. El uso de este sistema permite que las herramientas automatizadas inspeccionen su paquete y determinen el cumplimiento de SemVer y las versiones lanzadas.
- Al etiquetar comunicados en un sistema de control de versiones, la etiqueta para una versión debe ser "vX.Y.Z", por ejemplo,"v3.1.0".
No es que yo sepa.
Pero Git no permitirá que una etiqueta y una rama del mismo nombre, al mismo tiempo, por lo que si usted tiene una rama "1.1" para 1.1 funciona, no poner una etiqueta de "1.1", utilice por ejemplo "v1.1"
Uso para ramas 1.1.x. Eso es. – vitalii
No hay una mejor práctica que yo sepa. Estos son algunos enlaces:
En general, control de versiones (0.0.1, v0.2.1, ...) tal vez de la mano de algunos de seguimiento de problemas se podrían considerar un enfoque plausible. (.. aunque yo suelo usar v nombres de las etiquetas -prefixed .. véase también @VonC responder)
Utilizamos las ramas y etiquetas para el trabajo específico de la versión seguido de la liberación real, respectivamente:
o---o-----o---o---o--- ... master
\ / /
\/ /
o-------o--- ... 1.6 branch
Cada el desarrollador toma una decisión mental sobre si el trabajo que está a punto de comprometer es aplicable solo para dominar o si también es relevante para la sucursal. Puede ver que los cambios que se realizan en la rama se fusionan en el maestro, pero algunos cambios en el maestro nunca irán a la sucursal (es decir, los que no están destinados para la versión 1.6, en este ejemplo).
Cuando estamos listos para lanzarlos, los etiquetamos y luego los fusionamos por última vez, y nombramos la etiqueta con el mismo nombre que la rama, pero con un identificador adicional sobre la versión particular que es, p. "1.6-release" o "1.6-beta" o "1.6-rc2", etcétera.
... ------o---o---o--o---o--- ... master
/ /
/ /
... ---o------(*)--- ... 1.6 branch
1.6-release
Gracias - esa es una buena respuesta para describir cómo se ramifica, pero en realidad solo quería decir si había alguna razón específica (técnica) para usar un cierto esquema de nombres en git. Sin embargo, todavía te da un voto positivo por los buenos diagramas;) – troelskn
¡Ah, tengo! Perdón por malentender su pregunta. No, no hay una razón técnica específica para usar un nombre en particular, que no sea la comunicación humana. Puede nombrar sus ramas y etiquetas prácticamente como quiera. –
Su versión 1.6 de la rama se llama "1.6 rama"? Pensé que los espacios no eran compatibles con los nombres de las sucursales. –
No sé de ninguna norma. Simplemente elijo los nombres de mis etiquetas, de modo que puedo incluir un
VERSION = `git describe --tags`
en mis scripts de compilación. Entonces, la convención de nomenclatura de etiquetas en realidad depende de la convención de nomenclatura de la versión del proyecto.
git describe --tags:> –
Parece que hay dos convenciones dominantes (suponiendo que también permanecen por algún estándar razonable para la numeración de las notas de los propios):
v1.2.31.2.3Las ventajas de v1.2.3 es que la documentación de Git (y también la documentación de Mercurial) usa esa forma t en sus ejemplos, y que varias "autoridades" como el Linux kernel, Git sí mismo, y el mencionado Semantic Versioning lo usan.
Las ventajas de 1.2.3 son que gitweb o GitHub pueden ofrecer automáticamente un archivo tar o zip descarga de la forma packagename-$tag.tar.gz (y yo creo que es bastante establecido que un archivo comprimido debe no ser nombrado package-v1.2.3.tar.gz). Alternativamente, puede usar git describe directamente para generar números de versión tarball. Para proyectos livianos sin un proceso de lanzamiento formal, estas posibilidades pueden ser bastante convenientes. También se debe tener en cuenta que la versión semántica no es de ninguna manera la única o una norma universalmente aceptada para la numeración de versiones. Y proyectos notables como GNOME e innumerables otros proyectos usan el nombre de etiqueta 1.2.3.
Creo que es demasiado tarde para consolidar estas posiciones. Como siempre, sea consecuente y tenga sentido.
Actualización: Como se mencionó en this comentario, GitHub ofrece ahora un nombre de archivo comprimido con la 'v' despojado de la etiqueta.
Con respecto a la generación de GitHub y tarball: ya no es relevante. Quitan la 'v' de la etiqueta. –
La prefijación de 'v' también es bastante útil al ordenar las etiquetas en orden alfabético. Otras etiquetas también pueden existir; ya sea oficialmente en un repositorio principal o para rastrear localmente el trabajo de un desarrollador. Con los prefijos 'v', las etiquetas de lanzamiento forman su propio grupo, en lugar de estar dispersas por todo el resto del espacio de nombres. –
El motivo de la 'v' anterior es histórico. Los SCCS antiguos (cvs, rcs) no podían distinguir entre un identificador de etiqueta y un número de revisión. Los identificadores de etiqueta estaban restringidos para que no comenzaran con un valor numérico para poder detectar los números de revisión.
+1: buena primera respuesta y un nombre de uno de mis libros favoritos :-) Tal vez su próxima respuesta será en una pregunta más actual, sin embargo. – Johnsyweb
... pero si esto solo es cierto para * SVCS * anteriores, ¿y si el objetivo de esta respuesta es una pregunta sobre el Git moderno? – MestreLion
esto sigue siendo útil en git, por lo que puede distinguir fácilmente etiquetas de versión, de otro tipo de etiquetas (las etiquetas son útiles para muchas otras cosas) – Benja
Nueva gestores de paquetes consejos para etiquetar versiones sin prefijo v (como composer proyectos PSP). SemVer 2.0 no tiene nada acerca de la especificación de la etiqueta. Se hace intencionalmente debido a evitar conflictos. Sin embargo, es aconsejó para agregar el prefijo v en documentación y referencias de texto. Como formato de ejemplo v1.0.4 en lugar de version 1.0.4 o ver. 1.0.4 completo es suficiente prolijo y elegante en la documentación.
"se aconseja ..." Asesorado por quién, y dónde podemos ver ese consejo en su contexto original? – bignose
Con 43 votaciones ascendentes y conteo, me pregunto si esta pregunta tan valiosa podría reformularse y volver a abrirse, con alguna respuesta que integre todos los puntos en un buen resumen y estar en la parte superior. @ PeterEisentraut parece ser el más completo; mientras que la respuesta aceptada ATM parece un poco engañosa. * (Creo que usaré la v1.2.3 para etiquetas yo mismo, después de leer todos los puntos.) * – HostileFork
Esta es una pregunta común con algunas respuestas muy útiles. No debería haber sido cerrado. –
SO es para corregir el código. Las mejores prácticas parecen pertenecer a https://softwareengineering.stackexchange.com/ o https://codereview.stackexchange.com/ –