Saltar al contenido principal

Flujo de Trabajo y Pull Requests

Uno de los principales motivos por los que usamos Git es la seguridad colaborativa. En un entorno real serio corporativo NADIE (ni siquiera los líderes técnicos) tiene en teoría permisos para subir código directamente a la rama main utilizando git push origin main.

Si todos pudieran "empujar" libremente código directo a producción, ¡cualquier error humano podría averiar la aplicación o borrar cosas críticas!

Para prevenirlo, todo código nuevo ingresa mediante solicitudes formales llamadas Pull Requests (PRs) en GitHub, o Merge Requests (MRs) en GitLab.

🛠️ El Ciclo Profesional Completo​

El flujo natural seguido por casi todas las empresas del planeta es el siguiente:

1. El Desvío (Branching)​

Un programador es asignado a construir un nuevo botón rojo para la página de inicio. Lo primero que hace en su computadora es bajarse lo más actual y derivar una rama exclusiva:

git switch main
git pull origin main
git switch -c feature/red-button

Ahora el desarrollador está en un ambiente "seguro" contenido. Todo lo que haga aquí no tocará el entorno oficial de main.

2. Desarrollo (Committing)​

El programador programa su código HTML, guarda los cambios paso a paso y empaqueta el paquete terminado en commits:

git add .
git commit -m "feat: Agrega estructura del botón rojo y animación CSS"

3. Subir la propuesta a revisión (Pushing)​

Ahora el desarrollador sube su rama independiente a los servidores y base de datos de GitHub.

git push -u origin feature/red-button

Su computadora ya hizo su trabajo, ahora toma el relevo la plataforma web de GitHub. Este último comando "subió la rama" con el código, pero main todavía no sabe que esto ocurrió ni ha absorbido el trabajo.

🚪 ¿Qué es un Pull Request (PR)?​

Es un formulario web formal donde tú, amablemente, le dices a los administradores del proyecto principal:

  • "Ey, tengo código nuevo listo en mi rama y propongo que me permitan incorporarlo al proyecto real de la empresa".

4. Creación del PR y Aprobaciones​

En GitHub, verás inmediatamente un botón verde luminoso arriba de los repositorios que dirá "Compare & pull request" después de hacer tu push. Le haces click. Puedes escribirle un título explicativo.

A partir de este momento:

  1. Todos los ingenieros (o compañeros) del equipo reciben notificación por mail o Slack de que hay un nuevo PR esperando.
  2. Ingresan a GitHub y revisan línea por línea el código que añadiste antes de ser aceptado.
  3. Te dejan "Comentarios" sugiriendo cambiar nombres de variables y te piden hacer mejoras ("Code Review").
  4. Tú en tu computadora realizas los cambios requeridos, vuelves a hacer git commit y git push a tu misma rama, lo cual actualizará el PR por arte de magia en la nube.
  5. Cuando todo el equipo está de acuerdo que tu código está listo, pulsan un botón que dice "Aprobar" ("Approve").

5. Finalizar y Unir​

Una vez aprobado formalmente por pares, se hace click masivo en un botón verde enorme llamado "Merge Pull Request". Detrás de escenas, en la nube, los servidores de GitHub ejecutan el comando "Git Merge" y finalmente fusionan feature/red-button contra main.

Tu código finalmente está en rama principal. Tu ticket está resuelto. Misión cumplida. 🎉