Trabajo en equipo: PRs, review y convenciones

Flujos de trabajo

Un flujo (workflow) son las reglas de cómo el equipo lleva cambios a producción. Dos modernos y simples:

• GitHub flow: main siempre desplegable. Para cada cambio creas una rama corta, abres un Pull Request, se revisa, se fusiona y se despliega.
• Trunk-based development: todos integran muy a menudo (varias veces al día) en una sola rama principal (main/trunk) con ramas de vida muy corta. Evita ramas longevas que divergen y provocan fusiones dolorosas.

Ambos comparten la misma idea: ramas pequeñas y de vida corta, e integración frecuente.

git switch -c feature/carrito
# ... commits ...
git push -u origin feature/carrito   # sube la rama al remoto

Pull Request (PR)

Un Pull Request (o Merge Request) es una solicitud para fusionar tu rama en otra (normalmente main). No es un comando de Git: es una función de la plataforma (GitHub/GitLab) que añade, sobre el merge, un espacio de revisión:

• muestra el diff completo de los cambios,
• permite comentarios línea a línea y discusión,
• ejecuta la CI (tests, lint, build) automáticamente,
• registra aprobaciones antes de poder fusionar.

El code review es la revisión por otra persona: detecta errores, comparte conocimiento y mantiene la calidad. Pide aprobación, atiende los comentarios y solo entonces se fusiona.

Conventional Commits

Conventional Commits es una convención para los mensajes de commit con un formato fijo, legible por máquinas y humanos:

<tipo>[ámbito opcional]: <descripción>

[cuerpo opcional]

[pie opcional, p. ej. BREAKING CHANGE: ...]

Tipos habituales:

git commit -m "feat: añade filtro por categoría"   # nueva funcionalidad
git commit -m "fix: corrige el cálculo del total"   # corrección de bug
git commit -m "docs: actualiza el README"
git commit -m "refactor: extrae el servicio de pagos"
git commit -m "test: cubre el carrito vacío"
git commit -m "chore: actualiza dependencias"

Un cambio incompatible (rompe la API pública) se marca con ! o con un pie BREAKING CHANGE::

git commit -m "feat!: cambia la firma de createUser"

Ventaja: permite generar el changelog y decidir el salto de versión (semver) de forma automática a partir de los mensajes.

Protección de ramas y CODEOWNERS

En equipos, main se protege para que nadie pueda romperla. Reglas típicas:

• prohibir push directo: todo entra por PR;
• exigir N aprobaciones antes de fusionar;
• exigir que la CI pase (tests/lint en verde);
• prohibir force-push y borrado de la rama.

El archivo CODEOWNERS define quién es responsable (revisor obligatorio) de cada parte del código. Al tocar esos archivos, su dueño se añade automáticamente como revisor del PR:

# .github/CODEOWNERS
*.ts            @equipo-frontend
/infra/         @equipo-devops
/src/pagos/     @ana @luis