Skip to main content

Estrategia de ramas

El repositorio apolo-app-platcom-platform sigue una estrategia de ramas pensada para:

  • Proteger la rama principal (main)
  • Facilitar el trabajo paralelo entre equipos
  • Mantener un historial de cambios legible y trazable

Ramas principales​

  • main
    • Rama protegida.
    • Siempre debe estar en estado estable.
    • Solo se actualiza mediante pull requests aprobados.

Ramas de trabajo​

Todas las contribuciones deben hacerse desde ramas de trabajo creadas a partir de main:

Convenciones de nombres​

Usamos prefijos según el tipo de cambio:

  • feature/<resumen-corto> → Nuevas funcionalidades
    • Ej: feature/auditoria-filtros-por-rol
  • fix/<resumen-corto> → Corrección de bugs
    • Ej: fix/ajuste-paginacion-reportes
  • chore/<resumen-corto> → Tareas internas (scripts, refactor menor, devops)
    • Ej: chore/actualizar-version-nest
  • docs/<resumen-corto> → Cambios exclusivamente de documentación
    • Ej: docs/actualizar-architecture-diagrams

Usa nombres en kebab-case, claros y específicos.

Flujo de trabajo recomendado​

1. Crear la rama

git checkout main
git pull origin main
git checkout -b feature/<resumen-corto>

2. Commits frecuentes y pequeños

  • Cada commit debería representar un cambio coherente.

3. Mantener la rama actualizada

Antes de abrir el PR (o si tarda en aprobarse):

git checkout main
git pull origin main
git checkout feature/<resumen-corto>
git rebase main    # o git merge main, según la política del equipo

4. Abrir el Pull Request

  • Título descriptivo.
  • Indicar el tipo de cambio (feature, fix, chore, docs).
  • En la descripción:
    • Contexto breve
    • Qué se hizo
    • Cómo probarlo (comandos / endpoints / vistas afectadas)

Ramas de hotfix (producción)​

En caso de incidentes críticos en ambientes productivos:

  • Crear rama desde main: 
    git checkout main
    git pull origin main
    git checkout -b fix/hotfix-<descripcion-corta>
  • Aplicar corrección mínima necesaria.
  • Crear PR contra main.
  • Documentar claramente el impacto y, si aplica, replicar/refactorizar luego en código no urgente.

Reglas importantes​

  • ❌ No hacer commits directamente en main.
  • ✅ Siempre usar ramas con prefijo (feature/, fix/, etc.).
  • ✅ Un PR debe estar asociado a una tarea / ticket del tablero (Jira, Planner, etc. si aplica).
  • ✅ Si el cambio impacta múltiples áreas (backend, frontend, librerías), documentar claramente en el PR.