Flujo de Trabajo — Edifiko / Rappid Tech

Resumen del proceso interno de desarrollo. Para la documentación completa, consultá los links al final de cada sección.

Índice

1. Gestión de tareas (Jira + GitHub)
2. Control de versiones (SemVer)
3. Resolución de conflictos

1. Gestión de tareas (Jira + GitHub)

Entornos del proyecto

Jerarquía en Jira

• EPIC: Módulo o bloque grande (ej. NP-1 – Módulo de autenticación).
• Story: Conjunto de tareas de una funcionalidad concreta.
• Task: Acción técnica individual, siempre dentro de una Story.
• Bug: Error detectado en testing o producción, asociado a una Story o Epic.

Nomenclatura de ramas

Las ramas se crean desde Jira (Create branch) siguiendo el formato:

Estados del tablero

Naming de Pull Requests

Orden de merge

Requisitos antes de pasar a Code Review

• El proyecto compila sin errores (pnpm build).
• El entorno corre sin fallos (pnpm dev).
• No hay errores visibles en consola.
• El código está formateado y limpio.

Flujo del desarrollador (paso a paso)

# 1. Mover la tarea a "In Progress" en Jira

# 2. Crear la rama desde Jira y hacer checkout local
git checkout -b NP-45_TASK_create-api-service

# 3. Desarrollar la funcionalidad...

# 4. Verificar, agregar y commitear
git status
git add .
git commit -m "feat: create api service for properties"

# 5. Pushear al repositorio
git push --set-upstream origin NP-45_TASK_create-api-service

# 6. Abrir PR en modo Draft en GitHub

# 7. Al terminar: cambiar PR a "Ready for Review" y mover tarea a "Code Review" en Jira

📄 Documentación completa: 01 - Proceso de gestión de tareas

2. Control de versiones (SemVer)

Se utiliza Versionado Semántico (MAJOR.MINOR.PATCH) en todos los repositorios.

Nomenclatura de ramas y tags de versión

Flujo para crear una nueva versión

# 1. Actualizar la rama dev
git checkout dev
git pull upstream dev

# 2. Verificar que el build compile (asegúrate de que dev no esté corriendo)
pnpm build

# 3. Incrementar la versión (patch / minor / major según el caso)
npm version patch   # actualiza package.json, crea commit y tag automáticamente

# 4. Crear la rama de versión
git checkout -b BUMP_V1.2.1

# 5. Pushear la rama y los tags
git push upstream --tags
git push upstream BUMP_V1.2.1

# 6. Abrir PR desde BUMP_V1.2.1 hacia test
#    Incluir en la descripción un resumen de los cambios incluidos

📄 Documentación completa: 02 - Control de versiones

3. Resolución de conflictos

Los conflictos aparecen al integrar cambios de múltiples Tasks hacia una misma Story. GitHub mostrará el mensaje:

"This branch has conflicts that must be resolved"

Procedimiento

# 1. Actualizar la rama destino (Story)
git checkout NP-12_STORY_login-component
git pull upstream NP-12_STORY_login-component

# 2. Ir a tu rama (Task) y traer los cambios de la Story
git checkout NP-45_TASK_create-api-service
git merge NP-12_STORY_login-component

# 3. Resolver los conflictos con el Merge Editor de VS Code
#    - Current Change:  tu código (Task)
#    - Incoming Change: código de la Story
#    - Result:          versión final combinada

# 4. Confirmar la resolución
git add .
git commit -m "Resolve merge conflicts with NP-12_STORY_login-component"

# 5. Pushear — GitHub eliminará automáticamente el estado de conflicto en el PR
git push upstream NP-45_TASK_create-api-service

Reglas al resolver conflictos

• Priorizar el código más actualizado o validado.
• Nunca eliminar código ajeno sin entenderlo. Si hay dudas, consultá con el autor.
• Usá siempre el Merge Editor visual de VS Code en lugar de resolver por terminal.
• Hacé un único commit de resolución con mensaje claro.
• Verificá que el proyecto compile antes de pushear (pnpm build).
• Sincronizá tu rama con la Story frecuentemente para minimizar conflictos futuros.

📄 Documentación completa: 03 - Resolución de conflictos