Glosario · Git y GitHub · Fase 1
Pull request (PR)
Una propuesta formal, en GitHub, de fusionar una rama en otra: se ven los cambios, se comentan y se aprueban antes de unirlos.
✦Apagada: responde bien la pregunta del final para encenderla
También lo verás como: PR · PRs · pull requests · merge request · MR · solicitud de cambios
Analogía
Entregar el borrador para revisión antes de que vaya a imprenta.
El flujo
rama nueva → commits → git push → abrir PR → revisar el diff → aprobar → merge
Por qué usarlo aunque trabajes solo
- Es el punto natural de revisión: ves todos los cambios juntos, con el diff bien presentado.
- Vercel crea una vista previa con su propia dirección para cada PR: puedes mandársela al cliente para que apruebe antes de publicar (Fase 2).
- Cuando una IA trabaje de forma autónoma, te entregará su trabajo como PR para que lo revises (Fase 13).
No confundir con
git pull: bajar cambios. El nombre "pull request" confunde: viene de "pide que tiren (pull) de tus cambios". GitLab lo llama merge request, que se entiende mejor.
Un paso más: qué hay dentro de un pull request
Al abrir uno en GitHub verás:
- Título y descripción: qué cambia y por qué.
- Commits: las fotos que incluye.
- Files changed: el diff completo, archivo por archivo. Aquí se revisa.
- Comentarios: se puede comentar una línea concreta.
- Comprobaciones automáticas (cuando las montes): pruebas y la vista previa de Vercel.
- El botón Merge, que une los cambios a
main.
Hasta que alguien pulsa ese botón, main no ha cambiado. Esa es la gracia: es un sitio seguro donde mirar con calma antes de que algo llegue a producción.
Comprueba que lo entendiste