En el siguiente gráfico veremos cómo desarrollar creando ramas según el workflow git flow.

De la rama develop salen y se fusionan las ramas de las mejoras a implementar y las ramas de preparación de código a producción release-. Cuando hay un error en producción a corregir, crearemos una rama hotfix- que saldrá y se fusionará en master para desplegar a producción y en develop para continuar desarrollando las nuevas funcionalidades sin bugs.

Extension para automatizar GIT flow. https://github.com/nvie/gitflow. Ofrece comandos para facilitar la creacion de features, hotfix, etc…

Uso de tags

Git tiene la habilidad de etiquetar (tag) puntos específicos en la historia como importantes. Generalmente se usa esta funcionalidad para marcar puntos donde se ha lanzado alguna versión (E.g. v1.0).

Git usa dos tipos principales de etiquetas: ligeras y anotadas. Una etiqueta ligera es muy parecida a una rama que no cambia —un puntero a una confirmación específica—. Sin embargo, las etiquetas anotadas son almacenadas como objetos completos en la base de datos de Git. Tienen suma de comprobación; contienen el nombre del etiquetador, correo electrónico y fecha; tienen mensaje de etiquetado; y pueden estar firmadas y verificadas con GNU Privacy Guard (GPG). Generalmente se recomienda crear etiquetas anotadas para disponer de toda esta información; pero si por alguna razón quieres una etiqueta temporal y no quieres almacenar el resto de información, también tiene disponibles las etiquetas ligeras. https://git-scm.com

Podemos usar los tags para volver al estado del respositorio que marcan y aunque no se pueden realizar cambios sobre un tag, si que puedes cambiar a ellos como si fuera una rama:

Comandos

  • Listar tags: git tag
  • Crear tag:
    • Ligera: git tag v1.4
    • Anotada: git tag -a v1.4 -m ‘my version 1.4’
  • Mostrar el estado del repositorio en un tag: git show v1.4
  • Enviar tags al repositorio remoto: git push origin master –tag