Manual de Uso de Ramas en Git

Este manual detalla cómo gestionar y trabajar con las ramas de nuestro proyecto utilizando Git. Sigue estas instrucciones para garantizar un flujo de trabajo ordenado y coherente.

1. Estructura de las Ramas

• master: Esta es la rama principal del proyecto y contiene el código que ha sido aprobado y que es estable. Todas las nuevas funcionalidades y desarrollos deben partir de aquí.

• feature/*: Estas ramas se crean para desarrollar nuevas funcionalidades. Se derivan de master y se trabajan hasta que la funcionalidad esté completa.

• release/*: Estas ramas representan las versiones del sistema que están en producción. Actualmente, tenemos dos versiones principales:

  • release/jalisco
  • release/chiapas

  Además, si un release tiene un sufijo adicional, como chiapas-activos, indica una versión diferenciada o un fork de la versión principal.

2. Flujo de Trabajo

2.1 Creación de una Nueva Funcionalidad

1. Partir de master:

   • Siempre que necesites desarrollar una nueva funcionalidad, primero asegúrate de estar en la última versión de master:

     git checkout master
     git pull origin master
     
     

2. Crear una Rama de Funcionalidad:

   • Crea una nueva rama a partir de master para trabajar en tu funcionalidad:

     git checkout -b feature/nombre-de-la-funcionalidad
     
     

3. Desarrollar en la Rama de Funcionalidad:

   • Realiza todos los cambios necesarios en la rama feature/nombre-de-la-funcionalidad.

4. Finalizar la Funcionalidad:

   • Una vez completada, la funcionalidad debe ser revisada (mediante pull request o revisión de código). Cuando esté aprobada, se puede fusionar en master o en la rama release correspondiente.

2.2 Creación de un Nuevo Release

1. Partir de master o de una Rama de Release Existente:

   • Si el nuevo release es una versión completamente nueva, se debe partir de master:

     git checkout master
     git pull origin master
     git checkout -b release/nueva-version
     
     

   • Si el nuevo release es una actualización o una versión específica para una región, parte de la rama release correspondiente:

     git checkout release/chiapas
     git pull origin release/chiapas
     git checkout -b release/chiapas-activos
     
     

2. Desarrollar en la Rama de Release:

   • Realiza los cambios específicos necesarios para este release en la nueva rama de release.

3. Publicar el Release:

   • Una vez que la rama de release esté lista para producción, asegúrate de fusionarla en master si es necesario, o mantenerla como una versión específica.

2.3 Mantener la Sincronización

• Mantener master Actualizado:
  • Asegúrate de que master siempre tenga la última versión de código estable.
• Sincronización de Ramas de Release:
  • Si una rama de release tiene cambios críticos o mejoras, estos deben ser considerados para su integración en master y en otras ramas de release relacionadas, si aplica.

3. Consideraciones Especiales