Flujo de trabajo
Ramas, nomenclatura ligada a Plane, formato de commits, políticas de combinación y plantilla de pull requests.
El equipo trabaja con dos ramas permanentes (main y develop) y una rama de trabajo por tarea. Las ramas de trabajo salen de develop y vuelven a ella por pull request; develop se lleva a producción una vez por semana.
Ramas
Ramas principales
| Rama | Propósito |
|---|---|
main | Refleja el código estable en producción. Siempre debe compilar y estar 100% funcional. |
develop | Rama de integración donde conviven los desarrollos terminados. Lo integrado aquí se compila para enviarse a producción una vez por semana. |
Ramas de trabajo
Se crean a partir de develop para trabajar en una tarea específica. Cuando la tarea termina y su pull request se aprueba, la rama se fusiona con develop y se elimina.
Nomenclatura de ramas e integración con Plane
Se usan las convenciones de nombres de ramas de Git (Git Branch Naming Conventions). La estructura es:
tipo/ID-de-Plane/descripcion-corta| Tipo | Uso | Ejemplo |
|---|---|---|
feature | Nueva funcionalidad | feature/APP-42-autenticacion-google |
bugfix | Corrección de un error | bugfix/APP-87-correccion-monto-carrito |
hotfix | Corrección urgente en producción | hotfix/APP-105-error-500-checkout |
release | Preparación de un lanzamiento | release/v1.2.0 |
El ID (APP-XX) es la clave de la tarea en Plane, así cada rama queda ligada a su tarea.
Formato de commits y enlace a Plane
Se adopta el estándar Conventional Commits 1.0.0. Para vincular los commits con Plane se incluye la clave de la tarea entre paréntesis al final del mensaje.
<tipo>(<módulo/ámbito>): <descripción corta> (<ID-PLANE>)
[cuerpo opcional con mayor detalle]Etiquetas: feat, fix, docs, style, refactor, perf, test, build, ci, chore.
Ejemplo:
feat(auth): desarrollo de la lógica para implementación de Google Auth (APP-42)
Se agregaron los endpoints, métodos y controladores para la integración
con la API de Google Auth.El significado de cada etiqueta está en Commits.
Políticas de combinación y protección
En GitHub (Settings → Branches → Branch protection rules) se configuran reglas estrictas para main y develop:
| Regla | Detalle |
|---|---|
| Pull request obligatorio | Require a pull request before merging, con al menos 1 aprobación de un miembro del equipo (Misael). |
| Sin push directo | Se prohíbe explícitamente hacer push directo a main y develop. |
| Borrado automático de ramas | Automatically delete head branches activado: la rama se elimina al hacer merge. |
Estrategia de merge
| Origen → destino | Estrategia | Por qué |
|---|---|---|
feature/*, bugfix/* → develop | Squash and merge | Mantiene el historial limpio: resume los commits temporales de la tarea en uno solo. |
release/*, hotfix/* → main | Create a merge commit | Conserva la trazabilidad completa del lanzamiento. |
Plantilla de pull requests
Todo pull request en GitHub usa la misma plantilla para estandarizar la revisión:
- Descripción de los cambios: breve explicación de qué hace el PR y qué problema resuelve.
- Vinculación con Plane: relacionado con la tarea APP-XX (enlace a la tarea en Plane).
- Pruebas realizadas: pruebas unitarias ejecutadas con éxito y verificación en entorno local.
- Capturas o videos (opcional): cambios de UI/UX, si aplica.
El archivo listo para copiar al repositorio está en Pull requests.
Ciclo de una tarea
Toma la tarea APP-XX en Plane y crea la rama desde develop actualizado.
Trabaja con commits pequeños que sigan Conventional Commits e incluyan el ID.
Sube la rama y abre el pull request hacia develop con la plantilla llena.
Espera la aprobación y atiende los comentarios de la revisión.
Haz squash and merge; la rama se borra sola y la tarea se cierra en Plane.
Los comandos paso a paso están en Ramas.