EST01: Estándar de ramas

Última edición: January 12, 2026 11:51 PM Propietario: Daniel C Etiquetas: Estándar Fecha de creación: August 15, 2025 6:01 PM

El propósito del estándar es establecer una estructura clara para la creación y gestión de ramas en los proyectos, definiendo cuándo y cómo crear ramas para nuevas funcionalidades, correcciones de errores y versiones de producción.

Nomenclatura de ramas

Para facilitar la identificación y gestión de las ramas.

Formato

✅

/__

Descripción de los componentes

• `` : Categoría de la tarea, como:
  • feat : cuando se trate de una nueva funcionalidad.
  • hotfix: cuando se trate de cambios urgentes y rápidos.
  • bugfix: para arreglar algún bug.
  • docs: algún cambio en la documentación (agregar procesos, políticas, estándares)
  • refactor: cuando se trate de una reorganización significativa de los elementos de un componente (agregar, separar o reorganizar código y/o textos en documentación)
  • test: ramas de prueba
• ``: Iniciales del desarrollador/es responsable/s de la rama.
• ``: identificador de la historia de usuario, proceso, política, o guía. Si no existe, utilizar no-ref.
• ``: breve descripción de la tarea o funcionalidad.

Ejemplos:

• Si Francisco Pérez Sánchez desarrolló una nueva funcionalidad relacionada a la historia de usuario US-27 y añadió cifrado JWT:

feat/FPS_US-27_cifrado-JWT

• María Gómez Hernández identificó un bug en la barra de navegación al cambiar de pestañas. No tiene una referencia relacionada por lo que llamó su rama:

bugfix/MGH_no-ref_corregir-navbar

Prácticas a seguir:

• Uso de guiones bajos y medios: Utiliza guiones bajos ( _ ) para separar cada segmento y guiones medios ( - ) para separar los elementos dentro de cada segmento.
• Descripciones claras y concisas: Asegurarse de que la `` sea breve pero suficientemente descriptiva para entender el propósito de la rama.
• Evitar caracteres especiales: No utilizar caracteres especiales o espacios en los nombres de las ramas para prevenir posibles conflictos.

Flujo de trabajo recomendado

Aquí se define la estrategia de ramificación y los roles claros para las diferentes ramas, así como los procedimientos para su interacción.

Ramas principales:

• main: Almacena el historial oficial de versiones en producción.
• develop: Sirve como rama de integración para funcionalidades en desarrollo.

Ramas de soporte:

• feature: Se crean a partir de develop para desarrollar nuevas características. Una vez completadas, se fusionan de nuevo en develop.
• release: Se crean a partir de develop cuando se considera que el conjunto de funcionalidades está listo para una nueva versión. Se utilizan para realizar pruebas finales, correcciones de errores y preparación de la documentación antes del lanzamiento. Una vez listas, se fusionan en main y en develop.
• hotfix: Se crea a partir de main para solucionar problemas críticos en producción. Después de la corrección se fusionan tanto en main como en develop para asegurar que la solución se refleje en futuras versiones.

Integración de cambios y manejo de conflictos

• Integración continua: fusionar regularmente las ramas de funcionalidad en develop para detectar y resolver conflictos de manera temprana.
• Revisión de código: Antes de fusionar cambios, realizar revisiones de código para mantener la calidad y coherencia del proyecto.
• Resolución de conflictos: En caso de conflictos durante la fusión, resolverlos en la rama correspondiente antes de completar la integración.