Flujo de Git - bootcamp-uchile-2026/grupo-2-backend GitHub Wiki

Flujo de Git

Esta página describe las convenciones de colaboración para el repositorio BuenOrigen Backend y el flujo acordado para el Hito 2. Se distinguen las reglas de trabajo del equipo de los ejemplos de comandos.

Repositorio y ramas

  • Repositorio: bootcamp-uchile-2026/grupo-2-backend.
  • Rama de integración: develop.
  • Rama principal: main (no es la rama de destino de los PR de desarrollo del Hito 2).
  • Cada tarea se desarrolla en una rama específica creada desde develop actualizada.
  • Los cambios se integran mediante Pull Request hacia develop, con revisión del equipo.

Regla obligatoria: issue y backlog antes de programar

Para toda tarea del backend (funcionalidades, correcciones, refactorizaciones, pruebas y documentación):

  1. Revisar los issues existentes y el tablero GitHub Projects grupo-2; evitar duplicados.
  2. Si ya existe un issue adecuado, trabajar bajo ese issue. Si no existe, crear uno en grupo-2-backend.
  3. Incorporar o vincular el issue al tablero grupo-2 y mantener su estado actualizado.
  4. Documentar alcance y criterios de aceptación antes de desarrollar.
  5. Relacionar el Pull Request con el issue y comprobar los criterios antes de cerrarlo.

El título y la descripción del issue deben indicar con claridad qué problema o necesidad se aborda. No se generan issues duplicados solo para seguir una secuencia de trabajo.

Convenciones de nombres

Ramas

Se utilizan prefijos convencionales, entre ellos:

feature/descripcion-breve
fix/descripcion-breve
refactor/descripcion-breve
docs/descripcion-breve
test/descripcion-breve

El nombre debe describir el cambio. Las tareas existentes pueden mantener el nombre con el que fueron creadas.

Commits

Los mensajes de commit se redactan en español, con un prefijo que describa el tipo de modificación:

fix: corregir validaciones de parámetros
refactor: unificar responsabilidades del servicio de productos
docs: actualizar contratos de la API
test: agregar pruebas de validación

No incluir números de issue en los mensajes de commit. La vinculación con el issue se realiza principalmente en el PR y GitHub Projects.

Nombres técnicos

Las clases, interfaces, modelos, DTOs, propiedades, métodos y demás identificadores de código se escriben en inglés. Las explicaciones y mensajes de commit permanecen en español. Las rutas HTTP existentes no se traducen automáticamente: son contratos que deben mantenerse coordinados con Frontend y Mobile.

Secuencia de trabajo

1. Actualizar develop

git switch develop
git fetch origin
git pull --ff-only origin develop

Si hay cambios locales sin guardar, resolverlos antes de actualizar.

2. Crear una rama dedicada

git switch -c fix/descripcion-del-cambio

El prefijo depende del alcance; fix/ es solo un ejemplo.

3. Implementar y comprobar

Revisar los criterios del issue, los contratos REST, los DTO y el impacto sobre Swagger y la Wiki. Ejecutar al menos las verificaciones aplicables:

npm run build
npm test

Los scripts concretos disponibles deben verificarse en el package.json vigente. La aprobación de un cambio requiere registrar qué comprobaciones se ejecutaron y su resultado; no asumir que las pruebas pasan sin ejecutarlas.

4. Confirmar y publicar

git status
git add <archivos-del-cambio>
git commit -m "fix: describir el cambio realizado"
git push -u origin fix/descripcion-del-cambio

Revisar git diff y git status antes del commit. Evitar incluir archivos no relacionados.

5. Abrir Pull Request hacia develop

El PR debe indicar:

  • Issue asociado en grupo-2-backend y estado en el tablero grupo-2.
  • Problema o requerimiento resuelto.
  • Resumen de los cambios.
  • Pruebas ejecutadas y resultados.
  • Impacto sobre endpoints, DTOs, Swagger, documentación y compatibilidad.
  • Aspectos pendientes o restricciones, si los hay.

Solicitar revisión de un compañero; resolver observaciones antes de integrar. El código y documentación se integran en develop siguiendo las decisiones del equipo.

6. Cierre

Después del merge, comprobar que el PR apunte a develop, actualizar el estado del issue en Projects y cerrar el issue cuando los criterios de aceptación estén cumplidos. No volver a auditar cambios previamente aprobados salvo nuevas evidencias de regresión o cambios posteriores.

Resolución de conflictos

Si develop cambió mientras se trabajaba en una rama, incorporar y resolver esos cambios de forma controlada. Antes de enviar un PR, revisar que no existan diferencias inesperadas ni un PR vacío. En caso de conflicto, no sobrescribir trabajo de compañeros sin revisar su intención.

Referencias