GUÍA / GitHub
Cómo funciona un Pull Request en un equipo de desarrollo
Aprende qué es un Pull Request, cómo se crea, qué ocurre durante el Code Review y cómo se integra una tarea en un flujo profesional de desarrollo.
Introducción: proponer un cambio
Un Pull Request (PR) es una propuesta para integrar los cambios de una rama en otra. Permite discutir el código y revisar su comportamiento antes de incorporarlo. Abrirlo no publica automáticamente tu trabajo en producción: el deploy depende del proyecto.
Qué vas a aprender y qué necesitas
Vas a seguir una tarea desde su ticket hasta el merge. Necesitas Git configurado, una cuenta de GitHub y permiso para colaborar en un repositorio de práctica. Si no tienes acceso de escritura, el equipo puede aceptar contribuciones mediante un fork.
Ticket → Branch → Desarrollo
Empieza por un ticket concreto: corregir el mensaje de un formulario cuando el correo es inválido. Define el resultado esperado y cómo comprobarlo. Actualiza main y crea una rama; evita mezclar la corrección con un rediseño. Desarrolla el cambio y prueba entradas válidas, inválidas y vacías.
git switch main
git pull --ff-only
git switch -c fix/validacion-correoCommit → Push → Pull Request
Revisa el diff antes de incluir archivos. Un commit debe contar un cambio coherente; el push lo comparte con el remoto. En GitHub abre el PR comparando tu rama con la rama base correcta. Resume el problema, la solución, las pruebas y cualquier limitación. Añade capturas si cambió la interfaz.
git diff
git add src/Formulario.jsx
git commit -m "fix: mostrar error para correo invalido"
git push -u origin fix/validacion-correoCode Review → Cambios solicitados
Quien revisa comprueba legibilidad, casos límite y coherencia con el proyecto. Puede comentar, aprobar o solicitar cambios. Responde explicando tu razonamiento; si discrepas, muestra un caso o una prueba. Corrige en la misma rama, crea otro commit y haz push: el PR se actualiza. No abras otro PR para cada comentario.
Aprobación → Merge
Solicita otra revisión cuando hayas atendido las observaciones. La aprobación puede no ser suficiente: las reglas del repositorio pueden exigir checks, resolver conversaciones o actualizar la rama. Ante un conflicto, entiende ambas versiones y prueba el resultado antes de marcarlo resuelto. Integra con el método acordado por el equipo y actualiza tu rama local.
Ejemplo de descripción revisable
Una buena descripción permite reproducir el cambio sin preguntarte todo por chat. Para el formulario: problema, no aparecía feedback al enviar un correo inválido; solución, validación y mensaje asociado al campo; pruebas, vacío, formato incorrecto y dirección válida. Indica qué no cubre la tarea, como la validación final en el servidor.
Errores comunes y buenas prácticas
Evita PR enormes, secretos en commits y frases como “ya funciona” sin evidencia. Revisa tu propio diff, elimina cambios accidentales y mantén los comentarios centrados en el código. Un PR pequeño facilita detectar defectos, pero no garantiza que esté libre de ellos.
Qué practicar después
Abre un PR de práctica, pide a otra persona una observación concreta y responde con un cambio comprobable. Explica por qué lo aceptaste o qué alternativa propones. Verifica el comportamiento después del merge y conserva el enlace como evidencia de colaboración.