Tagging & Versioning en Git

Lección 51 / 53

Git Guía Git Guía Git español

Siempre teniendo en cuenta que Git en sí mismo no es prescriptivo en el uso de etiquetas, son etiquetas que apuntan a un solo commit, para una gestión eficiente de un proyecto, es recomendable definir algunas pautas relacionadas con el uso de etiquetas en Git.

Podemos decir que las etiquetas de Git se suelen utilizar para indicar una determinada versión o lanzamiento del software. Las modalidades específicas pueden depender de un proyecto a otro. Por ejemplo, los proyectos que esperan que la versión actual se guarde en un archivo determinado pueden tener un commit donde se guarda la versión y agregar una etiqueta con la misma versión a ese commit. Otros proyectos pueden etiquetar cualquier commit como una versión (recuerda siempre que un commit es un snapshot).

De manera similar a lo que vimos anteriormente para los commit convencionales, también existen varias convenciones para versionar un proyecto de software, una de las más conocidas es la semantic versioning o semver.

En el semantic versioning la versión se representa mediante tres números, separados por un punto, cada uno de los cuales representa cómo ha cambiado la nueva versión o lanzamiento en comparación con la anterior, en particular:

es primer número es la major version, que aumentará cuando el cambio sea compatible con versiones anteriores
el segundo número es la minor version, que aumentará a medida que se agreguen funciones, pero aún es compatible con versiones anteriores
el tercer número es la patch version, que aumentará al corregir errores compatibles con versiones anteriores

Con esta convención podemos entender que:

0.2.0 - es un proyectos en las fases iniciales de desarrollo (la versión major es 0), no está dicho que cambiará de forma compatible
1.0.0 - es la primera versión “oficial”
1.0.3 - es el tercer lanzamiento de fix de la versión 1.0, no hay nuevas funciones respecto a la 1.0, sino solo correcciones de errores
1.1.0 - es el primer lanzamiento con nuevas funciones de la versión 1, pero todavía compatible con la versión 1
2.0.0 - es el primer lanzamiento no compatible con la versión 1
2.1.0-alpha.1 - es un pre lanzamiento de la futura versión 2.1.0

La información adicional sobre el semantinc versioning la podéis encontrar en Semver.

Desde el punto de vista de las etiquetas de Git, si se sigue el semantic versioning, la sugerencia es usar el número de versión con la letra v delante como etiqueta. Por lo tanto, las etiquetas en este caso serían v0.2.0, v1.0.3, v1.1.0, v2.1.0-alpha.1 y así sucesivamente.

Obviamente, las etiquetas de Git son útiles para marcar qué commit (y, por lo tanto, qué snapshot de la base de código) corresponde a una determinada versión o lanzamiento, pero para mantener posiblemente dos "líneas de desarrollo" (por ejemplo, trabajando en la versión 2 mientras se continúa dando soporte a la versión 1), será necesario encontrar otros modos y flujos de trabajo basados en otras características de Git (por ejemplo, branch)

50 Mensajes de commit e..

52 La opción merge en ..

Guía Git en español 1 ¿Qué es Git? 2 Nacimiento de Git 3 Principales características de Git 4 Línea de comando UI en Git 5 Cómo instalar Git 6 5 comandos Git para desarrolladores individuales 7 5 comandos Git para desarrollar en colaboración 8 Repository en Git 9 Commit en Git 10 Working Copy en Git 11 Staging Area en Git 12 Branch en Git 13 Remote en Git 14 Inicializar un nuevo repository con git init 15 Crear una copia de un repository remoto en Git con git clone 16 Configurar las opciones de Git con git config 17 El comando Git add en Git 18 El comando Git commit en Git 19 El comando Git diff en Git 20 El comando Git stash en Git 21 .gitignore : los archivos ignored en Git 22 El comando Git status en Git 23 El comando Git log en Git 24 El comando Git tag en Git 25 El comando Git blame en Git 26 El comando Git checkout en Git 27 El comando Git revert en Git 28 El comando Git reset en Git 29 El comando Git rm en Git 30 La opción Git commit –amend en Git 31 Git rebase –interactive en Git 32 Atajos para comandos frecuentes en Git 33 Repository compartido en Git 34 El modelo Fork & pull 35 El comando Git remote en Git 36 Los principales repository remote de Git: Github, Gitlab y Bitbucket 37 El comando Git fetch en Git 38 El comando Git push en Git 39 El comando Git pull en Git 40 El comando Git branch en Git 41 El comando Git checkout en Git 42 El comando Git merge en Git 43 Resolver un merge conflict en Git 44 Entender mejor el contenido de los commit durante un conflicto de merge en Git 45 Workflow Git centralizado 46 Workflow Git feature branching 47 Workflow Git trunk-based 48 Enfoque “forking” en Git 49 Gitflow en Git 50 Mensajes de commit en Git 51 Tagging & Versioning en Git 52 La opción merge en Git 53 La opción rebase en Git